Age | Commit message (Collapse) | Author |
|
See:
http://llvm.org/viewvc/llvm-project?view=revision&revision=187787
The newer version of newlib tickles this x86-32 bug
when building the exception handling tests, which don't
strip the "tail" attribute.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3702
Waiting on trybots, but it seems to have fixed the minimal
reproducer I have:
http://chromegw.corp.google.com/i/tryserver.nacl/builders/nacl-toolchain-linux-pnacl-x86_64/builds/922
http://chromegw.corp.google.com/i/tryserver.nacl/builders/nacl-toolchain-linux-pnacl-x86_32/builds/870
http://chromegw.corp.google.com/i/tryserver.nacl/builders/nacl-toolchain-mac-pnacl-x86_32/builds/875
R=jfb@chromium.org
Review URL: https://codereview.chromium.org/26538008
|
|
Cherry-pick r185186 from upstream.
Original commit message:
Author: Lang Hames <lhames@gmail.com>
Date: Fri Jun 28 18:36:42 2013 +0000
Add missing case to switch statement - DAGTypeLegalizer::ExpandIntegerResult
should expand ATOMIC_CMP_SWAP nodes the same way that it does for ATOMIC_SWAP.
Since ATOMIC_LOADs on some targets (e.g. older ARM variants) get legalized to
ATOMIC_CMP_SWAPs, the missing case had been causing i64 atomic loads to crash
during isel.
This has to be cherry-picked, as we have experienced the same bug described
in the original message. Missing case caused MIPS 64 atomics to crash.
TBR= mseaborn@chromium.org, dschuff@chromium.org
BUG= crash for MIPS atomics
Review URL: https://codereview.chromium.org/26958002
|
|
Localmods came from: https://codereview.chromium.org/10825082/, and earlier.
(1) The original change was so that byval parameters always
go on the stack. That part was added because the original
ARM code was buggy, and did not actually make a copy of the
value, modifying the caller's struct (ouch!).
(2) Then came a localmod to make all arguments following a
byval go on the stack and to make the var-args code aware of
that. This is so that arguments stay in the correct order
for var-args to pick up.
For (1) there has been some work upstream to make it work
better. In any case, clang with --target=armv7a-...-gnueabi
only used byval in some limited cases -- when the size of
the struct is > 64 bytes where the backend will know
that part of it could be in regs, and the rest can be
memcpy'ed to the stack.
For le32, clang will still generate byval without
satisfying the same ARM condition (only for structs
bigger than 64 bytes), so it could be *very bad* if
we didn't have the ABI simpification passes rewrite
the byval and try to let the ARM backend do things
with byval...
TEST=the GCC torture tests: va-arg-4.c, and 20030914-2.c
and the example in issue 2746 still pass.
BUG=none, cleanup
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/23691009
|
|
Conflicts:
docs/LangRef.rst
include/llvm/CodeGen/CallingConvLower.h
include/llvm/IRReader/IRReader.h
include/llvm/Target/TargetMachine.h
lib/CodeGen/CallingConvLower.cpp
lib/IRReader/IRReader.cpp
lib/IRReader/LLVMBuild.txt
lib/IRReader/Makefile
lib/LLVMBuild.txt
lib/Makefile
lib/Support/MemoryBuffer.cpp
lib/Support/Unix/PathV2.inc
lib/Target/ARM/ARMBaseInstrInfo.cpp
lib/Target/ARM/ARMISelLowering.cpp
lib/Target/ARM/ARMInstrInfo.td
lib/Target/ARM/ARMSubtarget.cpp
lib/Target/ARM/ARMTargetMachine.cpp
lib/Target/Mips/CMakeLists.txt
lib/Target/Mips/MipsDelaySlotFiller.cpp
lib/Target/Mips/MipsISelLowering.cpp
lib/Target/Mips/MipsInstrInfo.td
lib/Target/Mips/MipsSubtarget.cpp
lib/Target/Mips/MipsSubtarget.h
lib/Target/X86/X86FastISel.cpp
lib/Target/X86/X86ISelDAGToDAG.cpp
lib/Target/X86/X86ISelLowering.cpp
lib/Target/X86/X86InstrControl.td
lib/Target/X86/X86InstrFormats.td
lib/Transforms/IPO/ExtractGV.cpp
lib/Transforms/InstCombine/InstCombineCompares.cpp
lib/Transforms/Utils/SimplifyLibCalls.cpp
test/CodeGen/X86/fast-isel-divrem.ll
test/MC/ARM/data-in-code.ll
tools/Makefile
tools/llvm-extract/llvm-extract.cpp
tools/llvm-link/CMakeLists.txt
tools/opt/CMakeLists.txt
tools/opt/LLVMBuild.txt
tools/opt/Makefile
tools/opt/opt.cpp
|
|
This is no longer required, following our recent PNaCl ABI cleanups.
BUG=None
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/18031017
|
|
In a subsequent CL I'll clean up the whole IntrinsicLowering logic - probably
reverting it to upstream since we no longer really use it.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3526
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/18053017
|
|
This is no longer required, since Clang will not generate llvm.pow.*
intrinsics.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3513
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/18162002
|
|
* Don't preserve external linking for mem{cpy,move,cmp} during LTO.
* In the RewritePNaClLibraryCalls pass - add rewriting of mem* calls to
appropriate intrinsics, similarly to the way it was done for longjmp.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3493
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/17622003
|
|
if the function calls _builtin_unwind_init()
Also fix the list of callee-saved registers returned by
X86RegisterInfo::getCalleeSavedRegisters
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3486
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/16987002
|
|
Intrinsic::sin, Intrinsic::cos, etc., aren't generated.
Intrinsic::sqrt is implemented in hardware we support now.
If future hardware does not support it, we can supply
a library function in the runtime.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3339
TEST=scons, llvm test suite, gcc torture, spec2k
R=eliben@chromium.org
Review URL: https://codereview.chromium.org/16868002
|
|
to external function calls during the translation stage (llc).
One of the passes is a ModulePass that adds the appropriate function
declarations to the module. The other is a FunctionPass that performs the
actual call replacement. This split exists because of bitcode streaming.
Initially the passes handle the llvm.nacl.{set|long}jmp intrinsics. In the
future they may handle additional intrinsics that are part of the PNaCl
stable bitcode ABI.
This CL also removes the previous approach to handling this conversion
(in SelectionDAGBuilder.cpp). That ended up not working - more details in
issue 3429.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3429
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/16047002
|
|
------------------------------------------------------------------------
r182387 | jholewinski | 2013-05-21 07:37:16 -0700 (Tue, 21 May 2013) | 7 lines
Drop @llvm.annotation and @llvm.ptr.annotation intrinsics during codegen.
The intrinsic calls are dropped, but the annotated value is propagated.
Fixes PR 15253
Original patch by Zeng Bin!
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@182417 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r182344 | mren | 2013-05-20 17:57:22 -0700 (Mon, 20 May 2013) | 7 lines
Dwarf: use a single line table to generate assembly when .loc is used.
This is to fix PR15408 where an undefined symbol Lline_table_start1 is used.
Since we do not generate the debug_line section when .loc is used,
Lline_table_start1 is not emitted and we can't refer to it when calculating
at_stmt_list for a compile unit.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@182346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
stack slots (PR15707)
IR optimisation passes can result in a basic block that contains:
llvm.lifetime.start(%buf)
...
llvm.lifetime.end(%buf)
...
llvm.lifetime.start(%buf)
Before this change, calculateLiveIntervals() was ignoring the second
lifetime.start() and was regarding %buf as being dead from the
lifetime.end() through to the end of the basic block. This can cause
StackColoring to incorrectly merge %buf with another stack slot.
Fix by removing the incorrect Starts[pos].isValid() and
Finishes[pos].isValid() checks.
Just doing:
Starts[pos] = Indexes->getMBBStartIdx(MBB);
Finishes[pos] = Indexes->getMBBEndIdx(MBB);
unconditionally would be enough to fix the bug, but it causes some
test failures due to stack slots not being merged when they were
before. So, in order to keep the existing tests passing, treat LiveIn
and LiveOut separately rather than approximating the live ranges by
merging LiveIn and LiveOut.
This fixes PR15707.
Patch by Mark Seaborn.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3374
Review URL: https://codereview.chromium.org/15302009
|
|
This is similar to the way @llvm.{set|long}jmp are handled.
The previously defined nacl-specific intrinsics are no longer used
and are overridden.
For the library call, call setjmp/longjmp without a preceding
underscore as these symbols exist in our runtime support code
(pnacl/support/setjmp_XXX.S)
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3429
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/14715018
|
|
------------------------------------------------------------------------
r181296 | timurrrr | 2013-05-07 00:47:47 -0700 (Tue, 07 May 2013) | 1 line
Fix the VS2010 build broken by r181271
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@181379 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181271 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181227 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181226 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(Would sometimes optimize away conacts used to extend a vector with undef values)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://13782395
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181160 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181149 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Now even the small structures could be passed within byval (small enough
to be stored in GPRs).
In regression tests next function prototypes are checked:
PR15293:
%artz = type { i32 }
define void @foo(%artz* byval %s)
define void @foo2(%artz* byval %s, i32 %p, %artz* byval %s2)
foo: "s" stored in R0
foo2: "s" stored in R0, "s2" stored in R2.
Next AAPCS rules are checked:
5.5 Parameters Passing, C.4 and C.5,
"ParamSize" is parameter size in 32bit words:
-- NSAA != 0, NCRN < R4 and NCRN+ParamSize > R4.
Parameter should be sent to the stack; NCRN := R4.
-- NSAA != 0, and NCRN < R4, NCRN+ParamSize < R4.
Parameter stored in GPRs; NCRN += ParamSize.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181148 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constructor enables
Patch by Robert Wilhelm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181138 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
at all of the operands. Previously it was skipping over implicit operands which
cause infinite looping when the two-address pass try to reschedule a
two-address instruction below the kill of tied operand.
I'm unable to come up with a reasonably sized test case.
rdar://13747577
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180906 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
right now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180889 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
report a fatal error. This allows us to continue processing the translation
unit. Test case to come on the clang side because we need an inline asm
diagnostics handler in place.
rdar://13446483
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180873 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Optimize CONCAT_VECTOR nodes that merge EXTRACT_SUBVECTOR values that extract from the same vector.
rdar://13402653
PR15866
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180871 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
entire register is guaranteed to be preserved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180825 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
can express a"
because it breaks some buildbots.
This reverts commit 180816.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180819 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
register-indirect address with an offset of 0.
It used to be that a DBG_VALUE is a register-indirect value if the offset
(operand 1) is nonzero. The new convention is that a DBG_VALUE is
register-indirect if the first operand is a register and the second
operand is an immediate. For plain registers use the combination reg, reg.
rdar://problem/13658587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180816 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
I'll fix the heuristic in a general way in a follow-up commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180815 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
First, taking advantage of the fact that the virtual base registers are allocated in order of the local frame offsets, remove the quadratic register-searching behavior. Because of the ordering, we only need to check the last virtual base register created.
Second, store the frame index in the FrameRef structure, and get the frame index and the local offset from this structure at the top of the loop iteration. This allows us to de-nest the loops in insertFrameReferenceRegisters (and I think makes the code cleaner). I also moved the needsFrameBaseReg check into the first loop over instructions so that we don't bother pushing FrameRefs for instructions that don't want a virtual base register anyway.
Lastly, and this is the only functionality change, avoid the creation of single-use virtual base registers. These are currently not useful because, in general, they end up replacing what would be one r+r instruction with an add and a r+i instruction. Committing this removes the XFAIL in CodeGen/PowerPC/2007-09-07-LoadStoreIdxForms.ll
Jim has okayed this off-list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The `llvm.tls_init_funcs' (created by the front-end) holds pointers to the TLS
initialization functions. These need to be placed into the correct section so
that they are run before `main()'.
<rdar://problem/13733006>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180737 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Naturally, we should be able to pass in extra instructions, not just
extra blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180667 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to determine whether or not we're on a darwin platform for debug code
emitting.
Solves the problem of a module with no triple on the command line
and no triple in the module using non-gdb ok features on darwin. Fix
up the member-pointers test to check the correct things for cross
platform (DW_FORM_flag is a good prefix).
Unfortunately no testcase because I have no ideas how to test something
without a triple and without a triple in the module yet check
precisely on two platforms. Ideas welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Clarify documentation and API to make the difference between register and
register-indirect addressed locations more explicit. Put in a comment
to point out that with the current implementation we cannot specify
a register-indirect location with offset 0 (a breg 0 in DWARF).
No functionality change intended.
rdar://problem/13658587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
TLVs probably won't be as common as the other types of variables. Check for them
last before defaulting to "DATA".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180631 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
into account some previously misssed cases (PRE_DEC addressing mode, the offset and base address are swapped, etc). This should fix PR15581.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180609 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
scalars.
This already helps SSE2 x86 a lot because it lacks an efficient way to
represent a vector select. The long term goal is to enable the backend to match
a canonicalized pattern into a single instruction (e.g. vabs or pabs).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180597 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This is modelled on the Mach-O linker options implementation and should
support a Clang implementation of #pragma comment(lib/linker).
Reviewers: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D724
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vector types not returns a vector instead of a scalar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180254 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes PR15838. Need to check for blocks with nothing but dbg.value.
I'm not sure how to force this situation with a unit test. I tried to
reduce the test case in PR15838 (1k lines of metadata) but gave up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180227 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://13731657
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180226 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
For now, we just reschedule instructions that use the copied vregs and
let regalloc elliminate it. I would really like to eliminate the
copies on-the-fly during scheduling, but we need a complete
implementation of repairIntervalsInRange() first.
The general strategy is for the register coalescer to eliminate as
many global copies as possible and shrink live ranges to be
extended-basic-block local. The coalescer should not have to worry
about resolving local copies (e.g. it shouldn't attemp to reorder
instructions). The scheduler is a much better place to deal with local
interference. The coalescer side of this equation needs work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180193 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When MachineScheduler is enabled, this functionality can be
removed. Until then, provide a way to disable it for test cases and
designing MachineScheduler heuristics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180192 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180191 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180186 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
VSETCC without first checking the target's vector boolean contents.
This exposed an issue with PowerPC AltiVec where it appears it was setting the wrong vector boolean contents. The included change
fixes the PowerPC tests, and was OK'd by Hal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180129 91177308-0d34-0410-b5e6-96231b3b80d8
|