| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 93857
|
| |
|
|
|
|
|
| |
just like all other elf targets. Bruno, if this isn't right, please
let me know + why :)
llvm-svn: 93856
|
| |
|
|
| |
llvm-svn: 93855
|
| |
|
|
|
|
|
|
| |
I'm not sure that this is correct, but it causes no test failures,
and just emitting a .comm without protecting its linkage somehow
is surely not right.
llvm-svn: 93854
|
| |
|
|
| |
llvm-svn: 93853
|
| |
|
|
|
|
| |
"isdarwin".
llvm-svn: 93852
|
| |
|
|
|
|
|
|
|
|
| |
This makes a similar code dead in all the other targets, I'll clean it up
in a bit.
This also moves handling of lcomm up before acquisition of a section,
since lcomm never needs a section.
llvm-svn: 93851
|
| |
|
|
|
|
| |
darwin into common code.
llvm-svn: 93849
|
| |
|
|
|
|
|
|
|
| |
are the same. I had already fixed a similar problem where the source and
destination were different bitcasts derived from the same alloca, but the
previous fix still did not handle the case where both operands are exactly
the same value. Radar 7552893.
llvm-svn: 93848
|
| |
|
|
|
|
| |
duplicating the logic (differently) in lots of different targets.
llvm-svn: 93847
|
| |
|
|
|
|
| |
and everything else (weak).
llvm-svn: 93846
|
| |
|
|
| |
llvm-svn: 93845
|
| |
|
|
|
|
|
|
| |
GCC would put weak zero initialized mutable data in the .bss section,
we would put it into a crasy '.gnu.linkonce.b.test,"aw",@nobits'
section. Fixing this will allow simplifications next up.
llvm-svn: 93844
|
| |
|
|
|
|
|
|
|
| |
simplify and commonize some of the asmprinter logic for globals.
This also avoids printing the MCSection for .zerofill, which broke
the llvm-gcc build.
llvm-svn: 93843
|
| |
|
|
| |
llvm-svn: 93841
|
| |
|
|
| |
llvm-svn: 93839
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
1. TargetLoweringObjectFileMachO should decide if something
goes in zerofill instead of having every target do it.
2. TargetLoweringObjectFileMachO should assign said symbols to
the right MCSection, the asmprinters should just emit to the
right section.
3. Since all zerofill stuff goes through mcstreamer anymore,
MAI can have a bool "haszerofill" instead of having the textual
directive to emit.
llvm-svn: 93838
|
| |
|
|
| |
llvm-svn: 93835
|
| |
|
|
| |
llvm-svn: 93832
|
| |
|
|
| |
llvm-svn: 93831
|
| |
|
|
|
|
| |
and make sure we pick different instructions for ARM vs. Thumb2.
llvm-svn: 93829
|
| |
|
|
| |
llvm-svn: 93818
|
| |
|
|
|
|
|
|
|
| |
comments (fast isel, X86). This doesn't seem
to break any functionality, but will introduce
cases where -g affects the generated code. I'll
be fixing that.
llvm-svn: 93811
|
| |
|
|
|
|
| |
performance-critical code (currently only used by AsmWriter)
llvm-svn: 93802
|
| |
|
|
| |
llvm-svn: 93797
|
| |
|
|
|
|
| |
- Greatly improve the comments to the getLSDAEncoding method.
llvm-svn: 93796
|
| |
|
|
|
|
|
|
| |
aggressive changed the canonical form from sext(trunc(x)) to ashr(lshr(x)),
make sure to transform a couple more things into that canonical form,
and catch a case where we missed turning zext/shl/ashr into a single sext.
llvm-svn: 93787
|
| |
|
|
| |
llvm-svn: 93781
|
| |
|
|
|
|
| |
printing via <<. Otherwise we just print the pointer value.
llvm-svn: 93777
|
| |
|
|
|
|
|
|
|
|
| |
Instcombine does this but apparently there are situations where this pattern will escape the optimizer and / or created by isel. Here is a case that's seen in JavaScriptCore:
%t1 = sub i32 0, %a
%t2 = add i32 %t1, -1
The dag combiner pattern: ((c1-A)+c2) -> (c1+c2)-A
will fold it to -1 - %a.
llvm-svn: 93773
|
| |
|
|
|
|
| |
array
llvm-svn: 93764
|
| |
|
|
|
|
| |
Function* variable and smallptrset since function-local metadata cannot be cyclic
llvm-svn: 93762
|
| |
|
|
|
|
|
|
| |
the various MOV (register) instructions (16-bit Thumb), including tBRIND (the
indirect branch). Instead of '1', it should be specified as '?', because GPR
only specifies the register class, which includes both hi-and-lo registers.
llvm-svn: 93759
|
| |
|
|
|
|
|
| |
"On ARMv6T2 this turns cttz into rbit, clz instead of the 4 instruction
sequence it is now."
llvm-svn: 93758
|
| |
|
|
|
|
| |
because it points to an alloca instruction through metadata.
llvm-svn: 93757
|
| |
|
|
|
|
| |
.ll parser, but PR6070 wants it in the verifier too.
llvm-svn: 93756
|
| |
|
|
| |
llvm-svn: 93755
|
| |
|
|
|
|
|
|
| |
idea, but unfortunately necessary.
- Default to using 4-bytes for the LSDA pointer encoding to agree with the
encoded value in the CIE.
llvm-svn: 93753
|
| |
|
|
|
|
| |
the normal situation for non function-local metadata)
llvm-svn: 93748
|
| |
|
|
| |
llvm-svn: 93723
|
| |
|
|
|
|
|
| |
with the rest of the assembly output, is easier to read, and matches the
expected output for gcc's Neon tests.
llvm-svn: 93703
|
| |
|
|
| |
llvm-svn: 93702
|
| |
|
|
|
|
|
| |
as it emits code. Switch .globl directives to use OutStreamer instead of
doing it textually (in x86)
llvm-svn: 93700
|
| |
|
|
|
|
| |
printing them.
llvm-svn: 93699
|
| |
|
|
| |
llvm-svn: 93698
|
| |
|
|
|
|
|
| |
remove it and change all the code that prints MCSymbols to use
<< instead, which is much simpler and cleaner.
llvm-svn: 93695
|
| |
|
|
|
|
|
| |
for first character which is a digit, mangler would have taken care
of this already.
llvm-svn: 93694
|
| |
|
|
| |
llvm-svn: 93693
|
| |
|
|
|
|
| |
function, it is mangling types, which don't matter how they are done.
llvm-svn: 93692
|
| |
|
|
|
|
|
|
|
|
|
| |
to Mangler. Now MCSymbol just decides whether to slap quotes around
a symbol when printing it.
This also fixes some weirdness where two MCSymbols could be created
for the same symbol, if one needed to be mangled and got mangled to
the other one.
llvm-svn: 93690
|