| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
Original log:
Introduce a new ConstantVector::getSplat constructor function to
simplify a really common case.
llvm-svn: 148906
|
|
|
|
|
|
| |
simplify a really common case.
llvm-svn: 148901
|
|
|
|
|
|
| |
load an immediate.
llvm-svn: 148900
|
|
|
|
|
|
|
| |
did something extremely surprising, and shadowed actually useful
implementations that had completely different behavior.
llvm-svn: 148898
|
|
|
|
| |
llvm-svn: 148897
|
|
|
|
| |
llvm-svn: 148884
|
|
|
|
| |
llvm-svn: 148883
|
|
|
|
| |
llvm-svn: 148882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A REG_SEQUENCE instruction is lowered into a sequence of partial defs:
%vreg7:ssub_0<def,undef> = COPY %vreg20:ssub_0
%vreg7:ssub_1<def> = COPY %vreg2
%vreg7:ssub_2<def> = COPY %vreg2
%vreg7:ssub_3<def> = COPY %vreg2
The first def needs an <undef> flag to indicate it is the beginning of
the live range, while the other defs are read-modify-write. Previously,
we depended on LiveIntervalAnalysis to notice and fix the missing
<def,undef>, but that solution was never robust, it was causing problems
with ProcessImplicitDefs and the lowering of chained REG_SEQUENCE
instructions.
This fixes PR11841.
llvm-svn: 148879
|
|
|
|
| |
llvm-svn: 148878
|
|
|
|
|
|
| |
which is what N32/64 does.
llvm-svn: 148875
|
|
|
|
| |
llvm-svn: 148871
|
|
|
|
| |
llvm-svn: 148869
|
|
|
|
|
|
|
|
| |
When not using subsections via symbols, the assembler can resolve
symbol differences (including pcrel references) to non-local
labels at assembly time, not just those in the same atom.
llvm-svn: 148865
|
|
|
|
|
|
| |
instructions, for intel syntax.
llvm-svn: 148864
|
|
|
|
| |
llvm-svn: 148862
|
|
|
|
| |
llvm-svn: 148849
|
|
|
|
| |
llvm-svn: 148846
|
|
|
|
| |
llvm-svn: 148836
|
|
|
|
|
|
| |
accomodate every target I can think of offhand.
llvm-svn: 148833
|
|
|
|
| |
llvm-svn: 148832
|
|
|
|
| |
llvm-svn: 148825
|
|
|
|
| |
llvm-svn: 148821
|
|
|
|
| |
llvm-svn: 148819
|
|
|
|
| |
llvm-svn: 148818
|
|
|
|
| |
llvm-svn: 148815
|
|
|
|
| |
llvm-svn: 148806
|
|
|
|
| |
llvm-svn: 148805
|
|
|
|
|
|
|
|
| |
add a ConstantDataArray::getString method that corresponds to the (to be
removed) StringRef version of ConstantArray::get, but is dramatically more
efficient.
llvm-svn: 148804
|
|
|
|
|
|
| |
v8i16 -> v8i32, v4i32 -> v4i64 - used vpunpck* instructions.
llvm-svn: 148803
|
|
|
|
| |
llvm-svn: 148802
|
|
|
|
|
|
|
|
| |
This change adds an new option --arm-enable-ehabi-descriptors that
enables emitting unwinding descriptors. This provides a mode with a
working backtrace() without the (currently broken) exception support.
llvm-svn: 148800
|
|
|
|
|
|
| |
16 bits are sufficient to store attributes, tags and forms.
llvm-svn: 148799
|
|
|
|
|
|
|
|
| |
Saves about 1.5% on debug info size.
rdar://10278198
llvm-svn: 148794
|
|
|
|
|
|
|
|
| |
and clean up some other misc stuff. Unlike ConstantArray, we will
prefer to emit .fill directives for "String" arrays that all have
the same value, since they are denser than emitting a .ascii
llvm-svn: 148793
|
|
|
|
|
|
|
|
| |
same semantics as ConstantArray's but much more efficient because they
don't have to return std::string's. The ConstantArray methods will
eventually be removed.
llvm-svn: 148792
|
|
|
|
| |
llvm-svn: 148790
|
|
|
|
|
|
|
|
| |
instead of its own hard coded thing, allowing it to handle
ConstantDataSequential and fixing some obscure bugs (e.g. it would
previously crash on a CAZ of vector type).
llvm-svn: 148788
|
|
|
|
|
|
|
|
|
|
| |
out into a new ConstantFoldLoadThroughGEPIndices (more useful) function
and rewrite it to be simpler, more efficient, and to handle the new
ConstantDataSequential type.
Enhance ConstantFoldLoadFromConstPtr to handle ConstantDataSequential.
llvm-svn: 148786
|
|
|
|
|
|
| |
Make some CDS methods public.
llvm-svn: 148785
|
|
|
|
|
|
| |
This pacifies machine verifier
llvm-svn: 148782
|
|
|
|
|
|
|
| |
This won't have an effect until EliminateRegSequences() starts setting
the undef flags.
llvm-svn: 148779
|
|
|
|
|
|
| |
No need for 'getOperand' :)
llvm-svn: 148778
|
|
|
|
|
|
| |
loads are promoted to v2i64 or v4i64 so that no one tries to reintroduce pattern fragments for other types.
llvm-svn: 148771
|
|
|
|
| |
llvm-svn: 148764
|
|
|
|
| |
llvm-svn: 148762
|
|
|
|
| |
llvm-svn: 148761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
violation -- MC cannot depend on CodeGen.
Specifically, the MCTargetDesc component of each target is actually
a subcomponent of the MC library. As such, it cannot depend on the
target-independent code generator, because MC itself cannot depend on
the target-independent code generator. This change moved a flag from the
ARM MCTargetDesc file ARMMCAsmInfo.cpp to the CodeGen layer in
ARMException.cpp, leaving behind an 'extern' to refer back to it. That
layering order isn't viable givin the constraints outlined above.
Commandline flags are designed to be static specifically to avoid these
types of bugs.
Fixing this is likely going to require some non-trivial refactoring.
llvm-svn: 148759
|
|
|
|
| |
llvm-svn: 148757
|
|
|
|
| |
llvm-svn: 148755
|