| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
setup they require. Use this for ARM/Darwin to rematerialize the base
pointer from the frame pointer when required. rdar://8564268
llvm-svn: 116879
|
|
|
|
|
|
| |
truncate the stack pointer to 32-bits on a 64-bit machine.
llvm-svn: 116169
|
|
|
|
|
|
|
|
|
| |
of hardware signed integer conversion without
having to do a double cast (uint64_t --> double --> float). This is based on the algorithm from compiler_rt's __floatundisf
for X86-64.
llvm-svn: 115634
|
|
|
|
| |
llvm-svn: 114461
|
|
|
|
|
|
| |
MachinePointerInfo around more.
llvm-svn: 114452
|
|
|
|
|
|
| |
SelectionDAG::getExtLoad overload, and eliminate it.
llvm-svn: 114446
|
|
|
|
|
|
| |
getLoad overloads.
llvm-svn: 114443
|
|
|
|
|
|
|
| |
pass a completely incorrect SrcValue, which would result in a miscompile with
combiner-aa.
llvm-svn: 114411
|
|
|
|
|
|
|
| |
solve the root problem, but it corrects the bug in the code I added to
support legalizing in the case where the non-extended type is also legal.
llvm-svn: 112997
|
|
|
|
|
|
| |
lack sse2.
llvm-svn: 112175
|
|
|
|
| |
llvm-svn: 112104
|
|
|
|
|
|
|
| |
hierarchy with virtual methods and using llvm_unreachable to properly indicate
unreachable states which would otherwise leave variables uninitialized.
llvm-svn: 111803
|
|
|
|
|
|
|
|
|
|
|
| |
it involves specific floating-point types, legalize should expand an
extending load to a non-extending load followed by a separate extend operation.
For example, we currently expand SEXTLOAD to EXTLOAD+SIGN_EXTEND_INREG (and
assert that EXTLOAD should always be supported). Now we can expand that to
LOAD+SIGN_EXTEND. This is needed to allow vector SIGN_EXTEND and ZERO_EXTEND
to be used for NEON.
llvm-svn: 111586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correct alignment information, which simplifies ExpandRes_VAARG a bit.
The patch introduces a new alignment information to TargetLoweringInfo. This is
needed since the two natural candidates cannot be used:
* The 's' in target data: If this is set to the minimal alignment of any
argument, getCallFrameTypeAlignment would return 4 for doubles on ARM for
example.
* The getTransientStackAlignment method. It is possible for an architecture to
have argument less aligned than what we maintain the stack pointer.
llvm-svn: 108072
|
|
|
|
|
|
| |
for consistency sake.
llvm-svn: 107820
|
|
|
|
|
|
|
| |
than assuming a target will custom lower them. Targets which do so should
exlicitly mark them as having custom lowerings. PR7454.
llvm-svn: 107734
|
|
|
|
| |
llvm-svn: 107490
|
|
|
|
| |
llvm-svn: 107489
|
|
|
|
|
|
| |
This produces terrible but correct code.
llvm-svn: 106952
|
|
|
|
| |
llvm-svn: 106342
|
|
|
|
| |
llvm-svn: 106324
|
|
|
|
|
|
|
|
|
|
| |
entries used by llvm-gcc. *_[U]MIN and such can be added later if needed.
This enables the front ends to simplify handling of the atomic intrinsics by
removing the target-specific decision about which targets can handle the
intrinsics.
llvm-svn: 106321
|
|
|
|
|
|
| |
SDNode *, since it doesn't care about the ResNo value.
llvm-svn: 106282
|
|
|
|
| |
llvm-svn: 106278
|
|
|
|
|
|
| |
for correctness' sake, it should be there.
llvm-svn: 106229
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for the moment. The implementation of the libcall will follow.
Currently, the llvm-gcc knows when the intrinsics can be correctly handled by
the back end and only generates them in those cases, issuing libcalls directly
otherwise. That's too much coupling. The intrinsics should always be
generated and the back end decide how to handle them, be it with a libcall,
inline code, or whatever. This patch is a step in that direction.
rdar://8097623
llvm-svn: 106227
|
|
|
|
|
|
| |
sets the legalize action to Expand.
llvm-svn: 106203
|
|
|
|
|
|
| |
an alloca() or an llvm.stackrestore(). rdar://8031573
llvm-svn: 104900
|
|
|
|
|
|
|
|
| |
need to be promoted. The BUILD_VECTOR and EXTRACT_VECTOR_ELT nodes generated
here already allow the promoted type to be used without further changes, so
just do the promotion. This fixes part of pr7167.
llvm-svn: 104141
|
|
|
|
|
|
| |
one was subject to double rounding in extreme cases.
llvm-svn: 103744
|
|
|
|
| |
llvm-svn: 103489
|
|
|
|
|
|
| |
than just getting one through a TargetLowering.
llvm-svn: 101802
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
const_casts, and it reinforces the design of the Target classes being
immutable.
SelectionDAGISel::IsLegalToFold is now a static member function, because
PIC16 uses it in an unconventional way. There is more room for API
cleanup here.
And PIC16's AsmPrinter no longer uses TargetLowering.
llvm-svn: 101635
|
|
|
|
| |
llvm-svn: 101330
|
|
|
|
| |
llvm-svn: 100724
|
|
|
|
| |
llvm-svn: 100709
|
|
|
|
|
|
| |
need it anymore, so don't addRequire it.
llvm-svn: 100400
|
|
|
|
| |
llvm-svn: 98888
|
|
|
|
| |
llvm-svn: 98501
|
|
|
|
|
|
|
|
| |
(it seems that FreeBSD doesn't have copysignl). Done by
removing a bunch of assumptions from the code. This may also
help with sparc 128 bit floats.
llvm-svn: 98346
|
|
|
|
|
|
| |
conversions.
llvm-svn: 97854
|
|
|
|
| |
llvm-svn: 97781
|
|
|
|
| |
llvm-svn: 97779
|
|
|
|
|
|
|
|
|
| |
rounding correctly. This implementation is a generalization of
the x86_64 code in compiler-rt.
This fixes rdar://7683708.
llvm-svn: 97778
|
|
|
|
| |
llvm-svn: 97536
|
|
|
|
|
|
|
| |
operands are themselves vectors. Based on a patch by
Micah Villmow for PR6338.
llvm-svn: 97165
|
|
|
|
|
|
|
|
| |
terms of store and load, which means bitcasting between scalar
integer and vector has endian-specific results, which undermines
this whole approach.
llvm-svn: 97137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the number of value bits, not the number of bits of allocation for in-memory
storage.
Make getTypeStoreSize and getTypeAllocSize work consistently for arrays and
vectors.
Fix several places in CodeGen which compute offsets into in-memory vectors
to use TargetData information.
This fixes PR1784.
llvm-svn: 97064
|
|
|
|
| |
llvm-svn: 96240
|
|
|
|
| |
llvm-svn: 95781
|