Fixed build broken by b0fd0bdf657365125f1a96fa55195cedfc10ab24 #1

Closed
wants to merge 52 commits into
from

Conversation

Projects
None yet
5 participants

iakov commented Oct 17, 2012

Not tested for performance, but seems like code is the same as was meant in the original commit a069178 by @espindola. I'll kindly appreciate if @vargaz review my fix.

isanbard and others added some commits Apr 18, 2012

@isanbard isanbard Creating release_31 branch
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155051 91177308-0d34-0410-b5e6-96231b3b80d8
1e4dc1d
@isanbard isanbard Merging r155230:
------------------------------------------------------------------------
r155230 | void | 2012-04-20 13:31:44 -0700 (Fri, 20 Apr 2012) | 1 line

Modify the sh-bang to run out-of-the-box for FreeBSDes.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155231 91177308-0d34-0410-b5e6-96231b3b80d8
cd1395f
@isanbard isanbard Inline a variable that's used only in an assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155306 91177308-0d34-0410-b5e6-96231b3b80d8
a3c0de1
@isanbard isanbard Merging r155307:
------------------------------------------------------------------------
r155307 | void | 2012-04-22 00:23:04 -0700 (Sun, 22 Apr 2012) | 1 line

Remove some potential warnings about variables used uninitialized.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155308 91177308-0d34-0410-b5e6-96231b3b80d8
3bad18d
@isanbard isanbard Merging r155284:
------------------------------------------------------------------------
r155284 | chapuni | 2012-04-21 07:50:56 -0700 (Sat, 21 Apr 2012) | 1 line

CMake: Prune redundant LLVM_COMPILER_JOBS from llvm/CMakeLists.txt. HandleLLVMOptions.cmake has it.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155334 91177308-0d34-0410-b5e6-96231b3b80d8
90c3fce
@isanbard isanbard Merging r155285:
------------------------------------------------------------------------
r155285 | chapuni | 2012-04-21 07:51:02 -0700 (Sat, 21 Apr 2012) | 1 line

CMake: Enable LLVM_COMPILER_JOBS on all MS IDEs. We don't support older environments than VS9.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155335 91177308-0d34-0410-b5e6-96231b3b80d8
ec40315
@isanbard isanbard Merging r155342:
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155374 91177308-0d34-0410-b5e6-96231b3b80d8
d7d022a
@isanbard isanbard Merging r155288:
------------------------------------------------------------------------
r155288 | d0k | 2012-04-21 09:05:27 -0700 (Sat, 21 Apr 2012) | 6 lines

Remove unused PointerLikeTypeTraits for IndexListEntry.

It set NumLowBitAvailable = 3 which may not be true on all platforms.  We only
ever use 2 bits (the default) so this assumption can be safely removed

Should fix PR12612.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155375 91177308-0d34-0410-b5e6-96231b3b80d8
3a327a7
@isanbard isanbard Merging r155286:
------------------------------------------------------------------------
r155286 | chapuni | 2012-04-21 08:31:36 -0700 (Sat, 21 Apr 2012) | 1 line

HexagonISelLowering.cpp: Reorder #includes.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155377 91177308-0d34-0410-b5e6-96231b3b80d8
cd28ef9
@isanbard isanbard Merging r155287:
------------------------------------------------------------------------
r155287 | chapuni | 2012-04-21 08:31:45 -0700 (Sat, 21 Apr 2012) | 3 lines

llvm/lib/Target: [PR12611] Add "llvm/Support/raw_ostream.h" for Debug build on MSVC.

Thanks to Andy Gibbs, to report the issue.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155378 91177308-0d34-0410-b5e6-96231b3b80d8
3820dbe
@isanbard isanbard Merging r155466:
------------------------------------------------------------------------
r155466 | chandlerc | 2012-04-24 11:42:47 -0700 (Tue, 24 Apr 2012) | 17 lines

Fix a crash on valid (if UB) bitcode that is produced for some global
constants in C++11 mode. I have no idea why it required such particular
circumstances to get here, the code seems clearly to rely upon unchecked
assumptions.

Specifically, when we decide to form an index into a struct type, we may
have gone through (at least one) zero-length array indexing round, which
would have left the offset un-adjusted, and thus not necessarily valid
for use when indexing the struct type.

This is just an canonicalization step, so the correct thing is to refuse
to canonicalize nonsensical GEPs of this form. Implemented, and test
case added.

Fixes PR12642. Pair debugged and coded with Richard Smith. =] I credit
him with most of the debugging, and preventing me from writing the wrong
code.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155506 91177308-0d34-0410-b5e6-96231b3b80d8
4ade510
@isanbard isanbard Merging r155536:
------------------------------------------------------------------------
r155536 | lattner | 2012-04-24 23:37:20 -0700 (Tue, 24 Apr 2012) | 3 lines

openbsd doesn't support soname, patch by Brad Smith!


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155574 91177308-0d34-0410-b5e6-96231b3b80d8
c587f37
@isanbard isanbard Merging r155668:
------------------------------------------------------------------------
r155668 | atrick | 2012-04-26 14:48:25 -0700 (Thu, 26 Apr 2012) | 8 lines

Fix the SD scheduler to avoid gluing the same node twice.

DAGCombine strangeness may result in multiple loads from the same
offset. They both may try to glue themselves to another load. We could
insist that the redundant loads glue themselves to each other, but the
beter fix is to bail out from bad gluing at the time we detect it.

Fixes rdar://11314175: BuildSchedUnits assert.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155672 91177308-0d34-0410-b5e6-96231b3b80d8
a2cfd1f
@isanbard isanbard Merging r155818:
------------------------------------------------------------------------
r155818 | baldrick | 2012-04-30 04:56:58 -0700 (Mon, 30 Apr 2012) | 3 lines

Just mark the sign bit as known zero, rather than any other irrelevant bits
known zero in the LHS.  Fixes PR12541.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155827 91177308-0d34-0410-b5e6-96231b3b80d8
90671d4
@isanbard isanbard Merging r155809:
------------------------------------------------------------------------
r155809 | rafael | 2012-04-29 20:53:06 -0700 (Sun, 29 Apr 2012) | 2 lines

Make sure HoistInsertPosition finds a position that is dominated by all
inputs.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155828 91177308-0d34-0410-b5e6-96231b3b80d8
1f3f7a2
@isanbard isanbard Merging r155166:
------------------------------------------------------------------------
r155166 | void | 2012-04-19 16:31:07 -0700 (Thu, 19 Apr 2012) | 1 line

Put this expensive check below the less expensive ones.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155830 91177308-0d34-0410-b5e6-96231b3b80d8
3f3757b
@isanbard isanbard Merging r155813:
------------------------------------------------------------------------
r155813 | void | 2012-04-30 02:23:48 -0700 (Mon, 30 Apr 2012) | 1 line

Remove hack from r154987. The problem persists even with it, so it's not even a good hack.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155831 91177308-0d34-0410-b5e6-96231b3b80d8
54e9ce3
@isanbard isanbard Merging r155817:
------------------------------------------------------------------------
r155817 | void | 2012-04-30 03:44:54 -0700 (Mon, 30 Apr 2012) | 9 lines

Second attempt at PR12573:

Allow the "SplitCriticalEdge" function to split the edge to a landing pad. If
the pass is *sure* that it thinks it knows what it's doing, then it may go ahead
and specify that the landing pad can have its critical edge split. The loop
unswitch pass is one of these passes. It will split the critical edges of all
edges coming from a loop to a landing pad not within the loop. Doing so will
retain important loop analysis information, such as loop simplify.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155833 91177308-0d34-0410-b5e6-96231b3b80d8
b8813cd
@isanbard isanbard Rename to match coding conventions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155834 91177308-0d34-0410-b5e6-96231b3b80d8
17a1cbe
@isanbard isanbard Merging r155844:
------------------------------------------------------------------------
r155844 | spop | 2012-04-30 13:06:58 -0700 (Mon, 30 Apr 2012) | 8 lines

fix typo

Thanks to "Gabor Greif" <ggreif@gmail.com> for reporting this problem.

The configure flag should be --with-default-sysroot as documented, and
not --with-sysroot.  The reason we don't want to define --with-sysroot
is that GCC has a configure flag by that name and it has a different
semantics.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155852 91177308-0d34-0410-b5e6-96231b3b80d8
bd15df4
@isanbard isanbard Merging r155895:
------------------------------------------------------------------------
r155895 | eliben | 2012-04-30 23:15:40 -0700 (Mon, 30 Apr 2012) | 4 lines

Removed examples of stack frame inspection which no longer work for old JIT.
Added an example of MCJIT-based debugging.


------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155901 91177308-0d34-0410-b5e6-96231b3b80d8
80d99db
@isanbard isanbard Merging r155902:
------------------------------------------------------------------------
r155902 | void | 2012-05-01 01:27:43 -0700 (Tue, 01 May 2012) | 7 lines

Change the PassManager from a reference to a pointer.

The TargetPassManager's default constructor wants to initialize the PassManager
to 'null'. But it's illegal to bind a null reference to a null l-value. Make the
ivar a pointer instead.
PR12468

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155903 91177308-0d34-0410-b5e6-96231b3b80d8
3fb59ac
@isanbard isanbard Merging r155954:
------------------------------------------------------------------------
r155954 | void | 2012-05-01 15:50:45 -0700 (Tue, 01 May 2012) | 3 lines

Strip the pointer casts off of allocas so that the selection DAG can find them.
PR10799

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155955 91177308-0d34-0410-b5e6-96231b3b80d8
4f28317
@isanbard isanbard Merging r155984:
------------------------------------------------------------------------
r155984 | void | 2012-05-02 02:59:45 -0700 (Wed, 02 May 2012) | 4 lines

The value held in the vector may be RAUW'ed by some of the canonicalization
methods. Use a weak value handle to keep up with this.
PR12245

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@155985 91177308-0d34-0410-b5e6-96231b3b80d8
fe3d2c8
@isanbard isanbard New Revision: 155749
URL: http://llvm.org/viewvc/llvm-project?rev=155749&view=rev
Log:
Reapply 155668: Fix the SD scheduler to avoid gluing the same node twice.

This time, also fix the caller of AddGlue to properly handle
incomplete chains. AddGlue had failure modes, but shamefully hid them
from its caller. It's luck ran out.

Fixes rdar://11314175: BuildSchedUnits assert.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@156376 91177308-0d34-0410-b5e6-96231b3b80d8
d88807f
@isanbard isanbard s/3.1svn/3.1/g
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@156640 91177308-0d34-0410-b5e6-96231b3b80d8
b08aa24
@isanbard isanbard Update.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@156734 91177308-0d34-0410-b5e6-96231b3b80d8
5604a30
@DougGregor DougGregor Add some more release notes for Clang
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@156799 91177308-0d34-0410-b5e6-96231b3b80d8
27c0c5f
@isanbard isanbard Update.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@156862 91177308-0d34-0410-b5e6-96231b3b80d8
fa35f22
@isanbard isanbard Merge in 156319 156837 156838.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@156863 91177308-0d34-0410-b5e6-96231b3b80d8
b92bdea
@vargaz vargaz Add a 'mono' calling convention which allows us to pass an argument i…
…n a non-abi register.
8b361e5
@vargaz vargaz Allow intrinsics which throw exceptions. Allow them to be called usin…
…g invoke.

Add mono.load/mono.store intrinsics which are the same as load/store, and
lowered to the same code, but can throw exceptions. This enables support for
load/store operations which throw implicit exceptions.
b0fd0bd
@vargaz vargaz Add support for Mono EH to the JIT and the static compiler. For the J…
…IT, emit a variant of the C++ EH structures which contains extra information required by mono, i.e. the stack location of 'this'. For the static compiler, emit separate tables instead of the normal C++ tables.
602f719
@vargaz vargaz Handle buffer overflows during emission of EH info correctly. ace5f98
@vargaz vargaz Fix address space support in the X86 JIT. 6a3ed98
@vargaz vargaz Add x86.sse2.pause intrinsic. 458ba9b
@vargaz vargaz Add support for passing blockaddress-es as normal parameters in calls. b604594
@vargaz vargaz Add two mono specific flags in the form of custom metadata, which ma…
…ke it possible/easier for LLVM to hoist loads out of loops.
fc7a132
@vargaz vargaz Disable JIT debug info registration as it can become very slow when c…
…alled many times.
2728a52
@vargaz vargaz Add a workaround to the problem where the amd64 JIT would make all ca…
…lls as register indirect.
448b852
@vargaz vargaz Generate dwarf unwind info on arm. e01d6fc
@vargaz vargaz Implement emission of DWARF EH info on ARM. 1dbabae
@vargaz vargaz Workaround some problems in the ARMConstantIsland pass. 3a6d15a
@vargaz vargaz Avoid changing sqrt(nan) into undefined. 7da7066
@vargaz vargaz Add a -mono suffix to the output of llvm-config --version. 9f16f1b
@vargaz vargaz Remove unused IntrUnwind intrinsics attribute. 5c909e0
@vargaz vargaz Add missing file. 26b17d4
@vargaz vargaz Add missing files. d8e6c06
@vargaz vargaz Emit the function address encoding into the mono EH frame. 41a5119
@vargaz vargaz Fix ARM EH support which got broken by the last merge. 64effc0
@vargaz vargaz Fix merge problems. 65f2d00
@iakov iakov Fixed build broken by a069178 e2db1c8

Sorry, how is the build broken?

iakov commented Oct 17, 2012

@espindola I apologize for blaming you. I was confused by 'blame'. :) If I'm not wrong again, @vargaz moved some code out of ::visitLoad, but forgot Ranges variable.
BTW, I just want to build mono with llvm and have these build issue with 'mono' branch. Do I use proper source code?

I had no idea mono had its own branch, sorry.

Owner

vargaz commented Oct 17, 2012

master should build fine now, there was some interminent breakage.

@vargaz vargaz pushed a commit that referenced this pull request Oct 27, 2012

@stoklund stoklund Also combine zext/sext into selects for ARM.
This turns common i1 patterns into predicated instructions:

  (add (zext cc), x) -> (select cc (add x, 1), x)
  (add (sext cc), x) -> (select cc (add x, -1), x)

For a function like:

  unsigned f(unsigned s, int x) {
    return s + (x>0);
  }

We now produce:

  cmp r1, #0
  it  gt
  addgt.w r0, r0, #1

Instead of:

  movs  r2, #0
  cmp r1, #0
  it  gt
  movgt r2, #1
  add r0, r2

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162177 91177308-0d34-0410-b5e6-96231b3b80d8
792d657

@vargaz vargaz pushed a commit that referenced this pull request Jun 30, 2013

@chandlerc chandlerc Fix a use-after-free bug found by ASan. You can't assign a temporary
std::string to a StringRef. Moreover, the method being called accepts
a Twine to simplify these patterns.

Fixes this ASan failure:
==6312== ERROR: AddressSanitizer: heap-use-after-free on address 0x7fd558b1af58 at pc 0xcb7529 bp 0x7fffff572080 sp 0x7fffff572078
READ of size 1 at 0x7fd558b1af58 thread T0
    #0 0xcb7528 .../llvm/include/llvm/ADT/StringRef.h:192 llvm::StringRef::operator[]()
    #1 0x1d53c0a .../llvm/include/llvm/ADT/StringExtras.h:128 llvm::HashString()
    #2 0x1d53878 .../llvm/lib/Support/StringMap.cpp:64 llvm::StringMapImpl::LookupBucketFor()
    #3 0x1b6872f .../llvm/include/llvm/ADT/StringMap.h:352 llvm::StringMap<>::GetOrCreateValue<>()
    #4 0x1b61836 .../llvm/lib/MC/MCContext.cpp:109 llvm::MCContext::GetOrCreateSymbol()
    #5 0xe9fd47 .../llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp:154 (anonymous namespace)::ARMELFStreamer::EmitMappingSymbol()
    #6 0xea01dd .../llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp:133 (anonymous namespace)::ARMELFStreamer::EmitDataMappingSymbol()
    #7 0xe9f78b .../llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp:91 (anonymous namespace)::ARMELFStreamer::EmitBytes()
    #8 0x1b15d82 .../llvm/lib/MC/MCStreamer.cpp:89 llvm::MCStreamer::EmitIntValue()
    #9 0xcc0f9b .../llvm/lib/Target/ARM/ARMAsmPrinter.cpp:713 llvm::ARMAsmPrinter::emitAttributes()
    #10 0xcc0d44 .../llvm/lib/Target/ARM/ARMAsmPrinter.cpp:632 llvm::ARMAsmPrinter::EmitStartOfAsmFile()
    #11 0x14692ad .../llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:162 llvm::AsmPrinter::doInitialization()
    #12 0x1bc4677 .../llvm/lib/VMCore/PassManager.cpp:1561 llvm::FPPassManager::doInitialization()
    #13 0x1bc4990 .../llvm/lib/VMCore/PassManager.cpp:1595 llvm::MPPassManager::runOnModule()
    #14 0x1bc55e5 .../llvm/lib/VMCore/PassManager.cpp:1705 llvm::PassManagerImpl::run()
    #15 0x1bc5878 .../llvm/lib/VMCore/PassManager.cpp:1740 llvm::PassManager::run()
    #16 0xc3954d .../llvm/tools/llc/llc.cpp:378 compileModule()
    #17 0xc38001 .../llvm/tools/llc/llc.cpp:194 main
    #18 0x7fd557d6a11c __libc_start_main
0x7fd558b1af58 is located 24 bytes inside of 29-byte region [0x7fd558b1af40,0x7fd558b1af5d)
freed by thread T0 here:
    #0 0xc337da .../llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:56 operator delete()
    #1 0x1ee9cef .../libstdc++-v3/include/bits/basic_string.h:535 std::string::~string()
    #2 0xea01dd .../llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp:133 (anonymous namespace)::ARMELFStreamer::EmitDataMappingSymbol()
    #3 0xe9f78b .../llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp:91 (anonymous namespace)::ARMELFStreamer::EmitBytes()
    #4 0x1b15d82 .../llvm/lib/MC/MCStreamer.cpp:89 llvm::MCStreamer::EmitIntValue()
    #5 0xcc0f9b .../llvm/lib/Target/ARM/ARMAsmPrinter.cpp:713 llvm::ARMAsmPrinter::emitAttributes()
    #6 0xcc0d44 .../llvm/lib/Target/ARM/ARMAsmPrinter.cpp:632 llvm::ARMAsmPrinter::EmitStartOfAsmFile()
    #7 0x14692ad .../llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:162 llvm::AsmPrinter::doInitialization()
    #8 0x1bc4677 .../llvm/lib/VMCore/PassManager.cpp:1561 llvm::FPPassManager::doInitialization()
    #9 0x1bc4990 .../llvm/lib/VMCore/PassManager.cpp:1595 llvm::MPPassManager::runOnModule()
    #10 0x1bc55e5 .../llvm/lib/VMCore/PassManager.cpp:1705 llvm::PassManagerImpl::run()
    #11 0x1bc5878 .../llvm/lib/VMCore/PassManager.cpp:1740 llvm::PassManager::run()
    #12 0xc3954d .../llvm/tools/llc/llc.cpp:378 compileModule()
    #13 0xc38001 .../llvm/tools/llc/llc.cpp:194 main
    #14 0x7fd557d6a11c __libc_start_main

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169668 91177308-0d34-0410-b5e6-96231b3b80d8
8328bf7

@vargaz vargaz pushed a commit that referenced this pull request Jun 30, 2013

@isanbard isanbard Add a few more c'tors:
* One that accepts a single Attribute::AttrKind.

* One that accepts an Attribute::AttrKind plus a list of values. This is for
  attributes defined like this:

    #1 = attributes { align = 4 }

* One that accepts a string, for target-specific attributes like this:

    #2 = attributes { "cpu=cortex-a8" }


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171249 91177308-0d34-0410-b5e6-96231b3b80d8
500de7c

@vargaz vargaz pushed a commit that referenced this pull request Jun 30, 2013

@isanbard isanbard Parse the attribute group reference on a function.
Attribute references are of this form:

  define void @foo() #0 #1 #2 { ... }

Parse them for function attributes. If there's more than one reference, then
they are merged together.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174697 91177308-0d34-0410-b5e6-96231b3b80d8
04c4b56

@vargaz vargaz pushed a commit that referenced this pull request Jun 30, 2013

@isanbard isanbard TEMPORARY SYNTAX CHANGE!
The original syntax for the attribute groups was ambiguous. For example:

    declare void @foo() #1
    #0 = attributes { noinline }

The '#0' would be parsed as an attribute reference for '@foo' and not as a
top-level entity. In order to continue forward while waiting for a decision on
what the correct syntax is, I'm changing it to this instead:

     declare void @foo() #1
     attributes #0 = { noinline }

Repeat: This is TEMPORARY until we decide what the correct syntax should be.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174813 91177308-0d34-0410-b5e6-96231b3b80d8
f009ae6

@vargaz vargaz pushed a commit that referenced this pull request Jun 30, 2013

Kostya Serebryany [asan] Change the way we report the alloca frame on stack-buff-overflow.
Before: the function name was stored by the compiler as a constant string
and the run-time was printing it.
Now: the PC is stored instead and the run-time prints the full symbolized frame.
This adds a couple of instructions into every function with non-empty stack frame,
but also reduces the binary size because we store less strings (I saw 2% size reduction).
This change bumps the asan ABI version to v3.

llvm part.

Example of report (now):
==31711==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa77cf1c5 at pc 0x41feb0 bp 0x7fffa77cefb0 sp 0x7fffa77cefa8
READ of size 1 at 0x7fffa77cf1c5 thread T0
    #0 0x41feaf in Frame0(int, char*, char*, char*) stack-oob-frames.cc:20
    #1 0x41f7ff in Frame1(int, char*, char*) stack-oob-frames.cc:24
    #2 0x41f477 in Frame2(int, char*) stack-oob-frames.cc:28
    #3 0x41f194 in Frame3(int) stack-oob-frames.cc:32
    #4 0x41eee0 in main stack-oob-frames.cc:38
    #5 0x7f0c5566f76c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
    #6 0x41eb1c (/usr/local/google/kcc/llvm_cmake/a.out+0x41eb1c)
Address 0x7fffa77cf1c5 is located in stack of thread T0 at offset 293 in frame
    #0 0x41f87f in Frame0(int, char*, char*, char*) stack-oob-frames.cc:12  <<<<<<<<<<<<<< this is new
  This frame has 6 object(s):
    [32, 36) 'frame.addr'
    [96, 104) 'a.addr'
    [160, 168) 'b.addr'
    [224, 232) 'c.addr'
    [288, 292) 's'
    [352, 360) 'd'




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177724 91177308-0d34-0410-b5e6-96231b3b80d8
5bbdaac

@vargaz vargaz pushed a commit that referenced this pull request Jun 30, 2013

Jim Grosbach Legalize vector truncates by parts rather than just splitting.
Rather than just splitting the input type and hoping for the best, apply
a bit more cleverness. Just splitting the types until the source is
legal often leads to an illegal result time, which is then widened and a
scalarization step is introduced which leads to truly horrible code
generation. With the loop vectorizer, these sorts of operations are much
more common, and so it's worth extra effort to do them well.

Add a legalization hook for the operands of a TRUNCATE node, which will
be encountered after the result type has been legalized, but if the
operand type is still illegal. If simple splitting of both types
ends up with the result type of each half still being legal, just
do that (v16i16 -> v16i8 on ARM, for example). If, however, that would
result in an illegal result type (v8i32 -> v8i8 on ARM, for example),
we can get more clever with power-two vectors. Specifically,
split the input type, but also widen the result element size, then
concatenate the halves and truncate again.  For example on ARM,
To perform a "%res = v8i8 trunc v8i32 %in" we transform to:
  %inlo = v4i32 extract_subvector %in, 0
  %inhi = v4i32 extract_subvector %in, 4
  %lo16 = v4i16 trunc v4i32 %inlo
  %hi16 = v4i16 trunc v4i32 %inhi
  %in16 = v8i16 concat_vectors v4i16 %lo16, v4i16 %hi16
  %res = v8i8 trunc v8i16 %in16

This allows instruction selection to generate three VMOVN instructions
instead of a sequences of moves, stores and loads.

Update the ARMTargetTransformInfo to take this improved legalization
into account.

Consider the simplified IR:

define <16 x i8> @test1(<16 x i32>* %ap) {
  %a = load <16 x i32>* %ap
  %tmp = trunc <16 x i32> %a to <16 x i8>
  ret <16 x i8> %tmp
}

define <8 x i8> @test2(<8 x i32>* %ap) {
  %a = load <8 x i32>* %ap
  %tmp = trunc <8 x i32> %a to <8 x i8>
  ret <8 x i8> %tmp
}

Previously, we would generate the truly hideous:
	.syntax unified
	.section	__TEXT,__text,regular,pure_instructions
	.globl	_test1
	.align	2
_test1:                                 @ @test1
@ BB#0:
	push	{r7}
	mov	r7, sp
	sub	sp, sp, #20
	bic	sp, sp, #7
	add	r1, r0, #48
	add	r2, r0, #32
	vld1.64	{d24, d25}, [r0:128]
	vld1.64	{d16, d17}, [r1:128]
	vld1.64	{d18, d19}, [r2:128]
	add	r1, r0, #16
	vmovn.i32	d22, q8
	vld1.64	{d16, d17}, [r1:128]
	vmovn.i32	d20, q9
	vmovn.i32	d18, q12
	vmov.u16	r0, d22[3]
	strb	r0, [sp, #15]
	vmov.u16	r0, d22[2]
	strb	r0, [sp, #14]
	vmov.u16	r0, d22[1]
	strb	r0, [sp, #13]
	vmov.u16	r0, d22[0]
	vmovn.i32	d16, q8
	strb	r0, [sp, #12]
	vmov.u16	r0, d20[3]
	strb	r0, [sp, #11]
	vmov.u16	r0, d20[2]
	strb	r0, [sp, #10]
	vmov.u16	r0, d20[1]
	strb	r0, [sp, #9]
	vmov.u16	r0, d20[0]
	strb	r0, [sp, #8]
	vmov.u16	r0, d18[3]
	strb	r0, [sp, #3]
	vmov.u16	r0, d18[2]
	strb	r0, [sp, #2]
	vmov.u16	r0, d18[1]
	strb	r0, [sp, #1]
	vmov.u16	r0, d18[0]
	strb	r0, [sp]
	vmov.u16	r0, d16[3]
	strb	r0, [sp, #7]
	vmov.u16	r0, d16[2]
	strb	r0, [sp, #6]
	vmov.u16	r0, d16[1]
	strb	r0, [sp, #5]
	vmov.u16	r0, d16[0]
	strb	r0, [sp, #4]
	vldmia	sp, {d16, d17}
	vmov	r0, r1, d16
	vmov	r2, r3, d17
	mov	sp, r7
	pop	{r7}
	bx	lr

	.globl	_test2
	.align	2
_test2:                                 @ @test2
@ BB#0:
	push	{r7}
	mov	r7, sp
	sub	sp, sp, #12
	bic	sp, sp, #7
	vld1.64	{d16, d17}, [r0:128]
	add	r0, r0, #16
	vld1.64	{d20, d21}, [r0:128]
	vmovn.i32	d18, q8
	vmov.u16	r0, d18[3]
	vmovn.i32	d16, q10
	strb	r0, [sp, #3]
	vmov.u16	r0, d18[2]
	strb	r0, [sp, #2]
	vmov.u16	r0, d18[1]
	strb	r0, [sp, #1]
	vmov.u16	r0, d18[0]
	strb	r0, [sp]
	vmov.u16	r0, d16[3]
	strb	r0, [sp, #7]
	vmov.u16	r0, d16[2]
	strb	r0, [sp, #6]
	vmov.u16	r0, d16[1]
	strb	r0, [sp, #5]
	vmov.u16	r0, d16[0]
	strb	r0, [sp, #4]
	ldm	sp, {r0, r1}
	mov	sp, r7
	pop	{r7}
	bx	lr

Now, however, we generate the much more straightforward:
	.syntax unified
	.section	__TEXT,__text,regular,pure_instructions
	.globl	_test1
	.align	2
_test1:                                 @ @test1
@ BB#0:
	add	r1, r0, #48
	add	r2, r0, #32
	vld1.64	{d20, d21}, [r0:128]
	vld1.64	{d16, d17}, [r1:128]
	add	r1, r0, #16
	vld1.64	{d18, d19}, [r2:128]
	vld1.64	{d22, d23}, [r1:128]
	vmovn.i32	d17, q8
	vmovn.i32	d16, q9
	vmovn.i32	d18, q10
	vmovn.i32	d19, q11
	vmovn.i16	d17, q8
	vmovn.i16	d16, q9
	vmov	r0, r1, d16
	vmov	r2, r3, d17
	bx	lr

	.globl	_test2
	.align	2
_test2:                                 @ @test2
@ BB#0:
	vld1.64	{d16, d17}, [r0:128]
	add	r0, r0, #16
	vld1.64	{d18, d19}, [r0:128]
	vmovn.i32	d16, q8
	vmovn.i32	d17, q9
	vmovn.i16	d16, q8
	vmov	r0, r1, d16
	bx	lr

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179989 91177308-0d34-0410-b5e6-96231b3b80d8
1229792

@vargaz vargaz pushed a commit that referenced this pull request Nov 7, 2013

@dmpots dmpots 17309 ARM backend incorrectly lowers COPY_STRUCT_BYVAL_I32 for thumb1…
… targets

This commit implements the correct lowering of the
COPY_STRUCT_BYVAL_I32 pseudo-instruction for thumb1 targets.
Previously, the lowering of COPY_STRUCT_BYVAL_I32 generated the
post-increment forms of ldr/ldrh/ldrb instructions. Thumb1 does not
have the post-increment form of these instructions so the generated
assembly contained invalid instructions.

Passing the generated assembly to gcc caused it to complain with an
error like this:

  Error: cannot honor width suffix -- `ldrb r3,[r0],#1'

and the integrated assembler would generate an object file with an
invalid instruction encoding.

This commit contains a small test case that demonstrates the problem
with thumb1 targets as well as an expanded test case that more
throughly tests the lowering of byval struct passing for arm,
thumb1, and thumb2 targets.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192916 91177308-0d34-0410-b5e6-96231b3b80d8
0ca7df7

@vargaz vargaz pushed a commit that referenced this pull request Dec 9, 2013

@chandlerc chandlerc Fix an issue where SROA computed different results based on the relative
order of slices of the alloca which have exactly the same size and other
properties. This was found by a perniciously unstable sort
implementation used to flush out buggy uses of the algorithm.

The fundamental idea is that findCommonType should return the best
common type it can find across all of the slices in the range. There
were two bugs here previously:

1) We would accept an integer type smaller than a byte-width multiple,
   and if there were different bit-width integer types, we would accept
   the first one. This caused an actual failure in the testcase updated
   here when the sort order changed.
2) If we found a bad combination of types or a non-load, non-store use
   before an integer typed load or store we would bail, but if we found
   the integere typed load or store, we would use it. The correct
   behavior is to always use an integer typed operation which covers the
   partition if one exists.

While a clever debugging sort algorithm found problem #1 in our existing
test cases, I have no useful test case ideas for #2. I spotted in by
inspection when looking at this code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195118 91177308-0d34-0410-b5e6-96231b3b80d8
f4376c1

@vargaz vargaz pushed a commit that referenced this pull request Jan 27, 2014

@dmpots dmpots Add ARM fconsts/fconstd aliases for vmov.f32/vmov.f64
This commit adds the pre-UAL aliases of fconsts and fconstd for
vmov.f32 and vmov.f64. They use an InstAlias rather than a
MnemonicAlias to properly support the predicate operand.

We need to support encoded 8-bit constants in order to implement the
pre-UAL fconsts/fconstd aliases for vmov.f32/vmov.f64, so this
commit also fixes parsing of encoded floating point constants used
in vmov.f32/vmov.f64 instructions. Now we can support assembly code
like this:

  fconsts s0, #0x70

which is equivalent to vmov.f32 s0, #1.0.

Most of the code was already in place to support this feature.
Previously the code was trying to accept encoded 8-bit float
constants for the vmov.f32/vmov.f64 instructions.  It looks like the
support for parsing encoded floats was lost in a refactoring in
commit r148556 and we did not have any tests in place to catch it.

The change in this commit is to keep the parsed value as a 32-bit
float instead of a 64-bit double because that is what the isFPImm()
function expects to find. There is no loss of precision by using a
32-bit float here because we are still limited to an 8-bit encoded
value in the end.

Additionally, we explicitly reject encoded 8-bit floats for
vmovf.32/64. This is the same as the current behavior, but we now do
it explicitly rather than accidently.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198697 91177308-0d34-0410-b5e6-96231b3b80d8
0e5e9c3

@vargaz vargaz pushed a commit that referenced this pull request Apr 9, 2014

Evan Cheng For functions with ARM target specific calling convention, when simpl…
…ify-libcall

optimize a call to a llvm intrinsic to something that invovles a call to a C
library call, make sure it sets the right calling convention on the call.

e.g.
extern double pow(double, double);
double t(double x) {
  return pow(10, x);
}

Compiles to something like this for AAPCS-VFP:
define arm_aapcs_vfpcc double @t(double %x) #0 {
entry:
  %0 = call double @llvm.pow.f64(double 1.000000e+01, double %x)
  ret double %0
}

declare double @llvm.pow.f64(double, double) #1

Simplify libcall (part of instcombine) will turn the above into:
define arm_aapcs_vfpcc double @t(double %x) #0 {
entry:
  %__exp10 = call double @__exp10(double %x) #1
  ret double %__exp10
}

declare double @__exp10(double)

The pre-instcombine code works because calls to LLVM builtins are special.
Instruction selection will chose the right calling convention for the call.
However, the code after instcombine is wrong. The call to __exp10 will use
the C calling convention.

I can think of 3 options to fix this.

1. Make "C" calling convention just work since the target should know what CC
   is being used.

   This doesn't work because each function can use different CC with the "pcs"
   attribute.

2. Have Clang add the right CC keyword on the calls to LLVM builtin.

   This will work but it doesn't match the LLVM IR specification which states
   these are "Standard C Library Intrinsics".

3. Fix simplify libcall so the resulting calls to the C routines will have the
   proper CC keyword. e.g.
   %__exp10 = call arm_aapcs_vfpcc double @__exp10(double %x) #1

   This works and is the solution I implemented here.

Both solutions #2 and #3 would work. After carefully considering the pros and
cons, I decided to implement #3 for the following reasons.

1. It doesn't change the "spec" of the intrinsics.
2. It's a self-contained fix.

There are a couple of potential downsides.
1. There could be other places in the optimizer that is broken in the same way
   that's not addressed by this.
2. There could be other calling conventions that need to be propagated by
   simplify-libcall that's not handled.

But for now, this is the fix that I'm most comfortable with.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203488 91177308-0d34-0410-b5e6-96231b3b80d8
f57d600

@vargaz vargaz pushed a commit that referenced this pull request May 19, 2014

@wmzhao wmzhao [ARM64] Prevent bit extraction to be adjusted by following shift
For pattern like ((x >> C1) & Mask) << C2, DAG combiner may convert it
into (x >> (C1-C2)) & (Mask << C2), which makes pattern matching of ubfx
more difficult.
For example:
Given
  %shr = lshr i64 %x, 4
  %and = and i64 %shr, 15
  %arrayidx = getelementptr inbounds [8 x [64 x i64]]* @arr, i64 0, %i64 2, i64 %and
  %0 = load i64* %arrayidx
With current shift folding, it takes 3 instrs to compute base address:
  lsr x8, x0, #1
  and x8, x8, #0x78
  add x8, x9, x8

If using ubfx, it only needs 2 instrs:
  ubfx  x8, x0, #4, #4
  add x8, x9, x8, lsl #3

This fixes bug 19589


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207702 91177308-0d34-0410-b5e6-96231b3b80d8
360d6e8

@vargaz vargaz pushed a commit that referenced this pull request Aug 3, 2014

Jim Grosbach AArch64: Constant fold converting vector setcc results to float.
Since the result of a SETCC for AArch64 is 0 or -1 in each lane, we can
move unary operations, in this case [su]int_to_fp through the mask
operation and constant fold the operation away. Generally speaking:
  UNARYOP(AND(VECTOR_CMP(x,y), constant))
      --> AND(VECTOR_CMP(x,y), constant2)
where constant2 is UNARYOP(constant).

This implements the transform where UNARYOP is [su]int_to_fp.

For example, consider the simple function:
define <4 x float> @foo(<4 x float> %val, <4 x float> %test) nounwind {
  %cmp = fcmp oeq <4 x float> %val, %test
  %ext = zext <4 x i1> %cmp to <4 x i32>
  %result = sitofp <4 x i32> %ext to <4 x float>
  ret <4 x float> %result
}

Before this change, the code is generated as:
  fcmeq.4s  v0, v0, v1
  movi.4s v1, #0x1        // Integer splat value.
  and.16b v0, v0, v1      // Mask lanes based on the comparison.
  scvtf.4s  v0, v0        // Convert each lane to f32.
  ret

After, the code is improved to:
  fcmeq.4s  v0, v0, v1
  fmov.4s v1, #1.00000000 // f32 splat value.
  and.16b v0, v0, v1      // Mask lanes based on the comparison.
  ret

The svvtf.4s has been constant folded away and the floating point 1.0f
vector lanes are materialized directly via fmov.4s.

Rather than do the folding manually in the target code, teach getNode()
in the generic SelectionDAG to handle folding constant operands of
vector [su]int_to_fp nodes. It is reasonable (as noted in a FIXME) to do
additional constant folding there as well, but I don't have test cases
for those operations, so leaving them for another time when it becomes
appropriate.

rdar://17693791

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213341 91177308-0d34-0410-b5e6-96231b3b80d8
bd55412

@vargaz vargaz pushed a commit that referenced this pull request Aug 23, 2014

@qcolombet qcolombet [PeepholeOptimizer] Refactor the advanced copy optimization to take a…
…dvantage of

the isRegSequence property.

This is a follow-up of r215394 and r215404, which respectively introduces the
isRegSequence property and uses it for ARM.

Thanks to the property introduced by the previous commits, this patch is able
to optimize the following sequence:
vmov	d0, r2, r3
vmov	d1, r0, r1
vmov	r0, s0
vmov	r1, s2
udiv	r0, r1, r0
vmov	r1, s1
vmov	r2, s3
udiv	r1, r2, r1
vmov.32	d16[0], r0
vmov.32	d16[1], r1
vmov	r0, r1, d16
bx	lr

into:
udiv	r0, r0, r2
udiv	r1, r1, r3
vmov.32	d16[0], r0
vmov.32	d16[1], r1
vmov	r0, r1, d16
bx	lr

This patch refactors how the copy optimizations are done in the peephole
optimizer. Prior to this patch, we had one copy-related optimization that
replaced a copy or bitcast by a generic, more suitable (in terms of register
file), copy.

With this patch, the peephole optimizer features two copy-related optimizations:
1. One for rewriting generic copies to generic copies:
PeepholeOptimizer::optimizeCoalescableCopy.
2. One for replacing non-generic copies with generic copies:
PeepholeOptimizer::optimizeUncoalescableCopy.

The goals of these two optimizations are slightly different: one rewrite the
operand of the instruction (#1), the other kills off the non-generic instruction
and replace it by a (sequence of) generic instruction(s).

Both optimizations rely on the ValueTracker introduced in r212100.

The ValueTracker has been refactored to use the information from the
TargetInstrInfo for non-generic instruction. As part of the refactoring, we
switched the tracking from the index of the definition to the actual register
(virtual or physical). This one change is to provide better consistency with
register related APIs and to ease the use of the TargetInstrInfo.

Moreover, this patch introduces a new helper class CopyRewriter used to ease the
rewriting of generic copies (i.e., #1).

Finally, this patch adds a dead code elimination pass right after the peephole
optimizer to get rid of dead code that may appear after rewriting.

This is related to <rdar://problem/12702965>.

Review: http://reviews.llvm.org/D4874


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216088 91177308-0d34-0410-b5e6-96231b3b80d8
75d1452

vargaz closed this Dec 1, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment