- Mar 26, 2014
-
-
Timur Iskhodzhanov authored
llvm-svn: 204795
-
Daniel Sanders authored
llvm-svn: 204793
-
Daniel Sanders authored
[mips] Move the CHECK lines in mips*-register-names.s to make it more obvious which CHECK matches with which insn This reveals a small mistake in mips-register-names.s ($sp is tested twice and $s8 is not tested) which will be fixed in a follow-up commit. llvm-svn: 204792
-
Timur Iskhodzhanov authored
llvm-svn: 204791
-
Timur Iskhodzhanov authored
Fix PR19239 - Add support for generating debug info for functions without lexical scopes and/or debug info at all llvm-svn: 204790
-
Timur Iskhodzhanov authored
llvm-svn: 204788
-
Rafael Espindola authored
This reverts commit r204781. I will follow up to with msan folks to see what is what they were trying to do with aliases to weak aliases. llvm-svn: 204784
-
Hal Finkel authored
These instructions are essentially the same as their Altivec counterparts, but have access to the larger VSX register file. llvm-svn: 204782
-
Rafael Espindola authored
Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204781
-
David Blaikie authored
Allows this test to pass on COFF platforms so we don't need to restrict this test to a single target anymore. llvm-svn: 204780
-
Rafael Espindola authored
The logic was incorrect for variables, causing them to end up in the wrong section if the section had an index >= 0xff00. llvm-svn: 204771
-
Quentin Colombet authored
Adds the different broadcast instructions to the ReplaceableInstrsAVX2 table. That way the ExeDepsFix pass can take better decisions when AVX2 broadcasts are across domain (int <-> float). In particular, prior to this patch we were generating: vpbroadcastd LCPI1_0(%rip), %ymm2 vpand %ymm2, %ymm0, %ymm0 vmaxps %ymm1, %ymm0, %ymm0 ## <- domain change penalty Now, we generate the following nice sequence where everything is in the float domain: vbroadcastss LCPI1_0(%rip), %ymm2 vandps %ymm2, %ymm0, %ymm0 vmaxps %ymm1, %ymm0, %ymm0 <rdar://problem/16354675> llvm-svn: 204770
-
Rafael Espindola authored
We need .symtab_shndxr if and only if a symbol references a section with an index >= 0xff00. The old code was trying to figure out if the section was needed ahead of time, making it a fairly dependent on the code actually writing the table. It was also somewhat conservative and would create the section in cases where it was not needed. If I remember correctly, the old structure was there so that the sections were created in the same order gas creates them. That was valuable when MC's support for ELF was new and we tested with elf-dump.py. This patch refactors the symbol table creation to another class and makes it obvious that .symtab_shndxr is really only created when we are about to output a reference to a section index >= 0xff00. While here, also improve the tests to use macros. One file is one section short of needing .symtab_shndxr, the second one has just the right number. llvm-svn: 204769
-
Hal Finkel authored
The VSX instruction set has two types of FMA instructions: A-type (where the addend is taken from the output register) and M-type (where one of the product operands is taken from the output register). This adds a small pass that runs just after MI scheduling (and, thus, just before register allocation) that mutates A-type instructions (that are created during isel) into M-type instructions when: 1. This will eliminate an otherwise-necessary copy of the addend 2. One of the product operands is killed by the instruction The "right" moment to make this decision is in between scheduling and register allocation, because only there do we know whether or not one of the product operands is killed by any particular instruction. Unfortunately, this also makes the implementation somewhat complicated, because the MIs are not in SSA form and we need to preserve the LiveIntervals analysis. As a simple example, if we have: %vreg5<def> = COPY %vreg9; VSLRC:%vreg5,%vreg9 %vreg5<def,tied1> = XSMADDADP %vreg5<tied0>, %vreg17, %vreg16, %RM<imp-use>; VSLRC:%vreg5,%vreg17,%vreg16 ... %vreg9<def,tied1> = XSMADDADP %vreg9<tied0>, %vreg17, %vreg19, %RM<imp-use>; VSLRC:%vreg9,%vreg17,%vreg19 ... We can eliminate the copy by changing from the A-type to the M-type instruction. This means: %vreg5<def,tied1> = XSMADDADP %vreg5<tied0>, %vreg17, %vreg16, %RM<imp-use>; VSLRC:%vreg5,%vreg17,%vreg16 is replaced by: %vreg16<def,tied1> = XSMADDMDP %vreg16<tied0>, %vreg18, %vreg9, %RM<imp-use>; VSLRC:%vreg16,%vreg18,%vreg9 and we remove: %vreg5<def> = COPY %vreg9; VSLRC:%vreg5,%vreg9 llvm-svn: 204768
-
NAKAMURA Takumi authored
llvm-svn: 204766
-
- Mar 25, 2014
-
-
Rafael Espindola authored
While at it, factor some logic into FragmentWriter. This will allow more code to be factored out of the fairly large ELFObjectWriter. llvm-svn: 204765
-
Meador Inge authored
When cross-compiling LLVM itself the configure/make scripts get confused when creating the needed build host tools. For example, building and configuring like: CC_FOR_BUILD='i686-pc-linux-gnu-gcc' CXX_FOR_BUILD='i686-pc-linux-gnu-g++' CXX='i686-mingw32-g++' CC='i686-mingw32-gcc' LD='i686-mingw32-ld' /scratch /meadori/llvm-trunk/src/trunk/configure --host=i686-mingw32 CC_FOR_BUILD='i686-pc-linux-gnu-gcc' CXX_FOR_BUILD='i686-pc-linux-gnu-g++' CXX='i686-mingw32-g++' CC='i686-mingw32-gcc' LD='i686-mingw32-ld' make causes the following build break: checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. The 'config.log' shows that i686-mingw32-gcc is being used to create executables for the build host. This patch fixes the problem by propogating the names of the build host tools via BUILD_* when configuring/making BuildTools. Original patch by Ekaterina Sanina. llvm-svn: 204760
-
Juergen Ributzka authored
llvm-svn: 204758
-
Hal Finkel authored
Although the first two operands are the ones that can be swapped, the tied input operand is listed before them, so we need to adjust for that. I have a test case for this, but it goes along with an upcoming commit (so it will come soon). llvm-svn: 204748
-
Hal Finkel authored
TableGen will create a lookup table for the A-type FMA instructions providing their corresponding M-form opcodes. This will be used by upcoming commits. llvm-svn: 204746
-
Matt Arsenault authored
Remove handling of select_cc, since it makes no sense to be there. This now does nothing, but I'll be adding some handling of other target nodes soon. llvm-svn: 204743
-
Duncan P. N. Exon Smith authored
Implement Pass::releaseMemory() in BlockFrequencyInfo and MachineBlockFrequencyInfo. Just delete the private implementation when not in use. Switch to a std::unique_ptr to make the logic more clear. <rdar://problem/14292693> llvm-svn: 204741
-
Duncan P. N. Exon Smith authored
<rdar://problem/14292693> llvm-svn: 204740
-
Juergen Ributzka authored
If getElementPtr uses a constant as base pointer, then make the constant opaque. This prevents constant folding it with the offset. The offset can usually be encoded in the load/store instruction itself and the base address doesn't have to be rematerialized several times. llvm-svn: 204739
-
Juergen Ributzka authored
The cost for the first four stackmap operands was always TCC_Free. This is only true for the first two operands. All other operands are TCC_Free if they are within 64bit. llvm-svn: 204738
-
Juergen Ributzka authored
Usually opaque constants shouldn't be folded, unless they are simple unary operations that don't create new constants. Although this shouldn't drop the opaque constant flag. This commit fixes this. Related to <rdar://problem/14774662> llvm-svn: 204737
-
Adam Nemet authored
This used to resort to splitting the 256-bit operation into two 128-bit shuffles and then recombining the results. Fixes <rdar://problem/16167303> llvm-svn: 204735
-
Adam Nemet authored
I found three implementations of this. This splits it out into a new function and uses it from the three places. My plan is to add a fourth use when lowering a vector_shuffle:v16i16. Compared the assembly output of test/CodeGen/X86 before and after. The only change is due to how the first PSHUFB was generated in LowerVECTOR_SHUFFLEv8i16. If the shuffle mask specified undef (i.e. -1), the old implementation would write -1 * 2 and -1 * 2 + 1 (254 and 255) in the control mask. Now we write 0x80. These are of course interchangeable since bit 7 decides if a constant zero is written in the result byte. The other instances of this code use 0x80 consistently. Related to <rdar://problem/16167303> llvm-svn: 204734
-
Richard Osborne authored
Summary: Previously the code didn't check if the before and after types for the store were pointers to different address spaces. This resulted in instcombine using a bitcast to convert between pointers to different address spaces, causing an assertion due to the invalid cast. It is not be appropriate to use addrspacecast this case because it is not guaranteed to be a no-op cast. Instead bail out and do not do the transformation. CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3117 llvm-svn: 204733
-
Richard Osborne authored
No functionality change. llvm-svn: 204732
-
Benjamin Kramer authored
PR19187. llvm-svn: 204731
-
Matt Arsenault authored
This is supposed to have the same store size and alignment as <4 x i32>, but currently is split into a 64-bit and 32-bit store. llvm-svn: 204729
-
Benjamin Kramer authored
If we have a loop of the form for (unsigned n = 0; n != (k & -32); n += 32) {} then we know that n is always divisible by 32 and the loop must terminate. Even if we have a condition where the loop counter will overflow it'll always hold this invariant. PR19183. Our loop vectorizer creates this pattern and it's also occasionally formed by loop counters derived from pointers. llvm-svn: 204728
-
Matt Arsenault authored
If GT/UGT or LT/ULT were set to expand, a comparison with a constant would replace it with the illegal cond code. There are several more places later in this function that will have the same basic problem. Theoretically R600 should hit this problem for a test, but for some reason it doesn't. llvm-svn: 204727
-
Evgeniy Stepanov authored
This may or may not fix the bots. R204720 did not. llvm-svn: 204721
-
Evgeniy Stepanov authored
This may or may not fix the bots. llvm-svn: 204720
-
Rafael Espindola authored
It is impossible to create a hard link to a non existing file, so create a dummy file, create the link an delete the dummy file. On windows one cannot remove the current directory, so chdir first. llvm-svn: 204719
-
Evgeniy Stepanov authored
Some bits of select result may be initialized even if select condition is not. https://code.google.com/p/memory-sanitizer/issues/detail?id=50 llvm-svn: 204716
-
Daniel Sanders authored
Differential Revision: http://llvm-reviews.chandlerc.com/D3171 llvm-svn: 204714
-
Cameron McInally authored
llvm-svn: 204713
-