| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 127678
|
| |
|
|
|
|
|
|
| |
- Remove PTX 1.4 code generation
- Change type of intrinsics to .v4.i32 instead of .v4.i16
- Add and/or/xor integer instructions
llvm-svn: 127677
|
| |
|
|
|
|
| |
MCFixupKind. This is the same technique that is used elsewhere in MC.
llvm-svn: 127676
|
| |
|
|
|
|
| |
when building with assertions disabled.
llvm-svn: 127675
|
| |
|
|
| |
llvm-svn: 127674
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
memory builtins as equivalent to malloc/free.
This is different from any attribute we have. For example, you can delete the
allocators when their result is unused, but you can't collapse two calls to the
same function, even if no global/memory state has changed in between. The
noalias return states that the result does not alias any other pointer, but
instcombine optimizes malloc() as though the result is non-null for the purpose
of eliminating unused pointers.
llvm-svn: 127673
|
| |
|
|
| |
llvm-svn: 127672
|
| |
|
|
| |
llvm-svn: 127671
|
| |
|
|
|
|
| |
*must-be-uninitialized* warnings are reported, with *maybe-uninitialized* under a separate flag. I await any fallout/comments/feedback, although hopefully this will produce no noise for users.
llvm-svn: 127670
|
| |
|
|
|
|
| |
and "may-be-initialized" warnings, each controlled by different flags.
llvm-svn: 127669
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
v2 = bitcast v1
...
v3 = bitcast v2
...
= v3
=>
v2 = bitcast v1
...
= v1
if v1 and v3 are of in the same register class.
bitcast between i32 and fp (and others) are often not nops since they
are in different register classes. These bitcast instructions are often
left because they are in different basic blocks and cannot be
eliminated by dag combine.
rdar://9104514
llvm-svn: 127668
|
| |
|
|
|
|
|
| |
nothing more than a bitcast.
- Teach tablegen to automatically infer "Bitcast" property.
llvm-svn: 127667
|
| |
|
|
|
|
| |
and "may-be-initialized" warnings, each controlled by different flags.
llvm-svn: 127666
|
| |
|
|
|
|
| |
llvm::BitVector. No real functionality change, but this is a stepping stone to moving to tri-state logic.
llvm-svn: 127665
|
| |
|
|
|
|
| |
No functionality change. This defines the minimum interface that ValueVector needs to support when we no longer base it strictly on a direct interpretation of BitVector.
llvm-svn: 127664
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 127663
|
| |
|
|
|
|
|
|
| |
for templatized types that could cause parts of a std::vector (and I am sure
other STL types) to be incorrectly uniqued to each other wreaking havoc on
variable display for types within the same executable module.
llvm-svn: 127662
|
| |
|
|
|
|
| |
easier since "short" ends up with "short int" in the template allocators.
llvm-svn: 127661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types that have different contents. Currently LLDB is incorrectly uniquing,
on MacOSX, the std::vector _VectorImpl class from the two different vector
templates. The DWARF looks like:
0x0000008e: DW_TAG_structure_type [7] *
DW_AT_name( "_Vector_base<int,std::allocator<int> >" )
DW_AT_declaration( 0x01 )
DW_AT_sibling( {0x00000103} )
0x00000098: DW_TAG_structure_type [8] *
DW_AT_name( "_Vector_impl" )
DW_AT_byte_size( 0x18 )
DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
DW_AT_decl_line( 83 )
0x000000a0: DW_TAG_inheritance [9]
DW_AT_type( {0x000006fa} ( allocator<int> ) )
DW_AT_data_member_location( +0 )
DW_AT_accessibility( DW_ACCESS_public )
0x0000011b: DW_TAG_structure_type [7] *
DW_AT_name( "_Vector_base<short int,std::allocator<short int> >" )
DW_AT_declaration( 0x01 )
DW_AT_sibling( {0x00000190} )
0x00000125: DW_TAG_structure_type [8] *
DW_AT_name( "_Vector_impl" )
DW_AT_byte_size( 0x18 )
DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
DW_AT_decl_line( 83 )
0x0000012d: DW_TAG_inheritance [9]
DW_AT_type( {0x00000f75} ( allocator<short int> ) )
DW_AT_data_member_location( +0 )
DW_AT_accessibility( DW_ACCESS_public )
In this case it using DIE 0x00000098 for both 0x00000098 and 0x00000125.
This test will help detect this issue once I have a fix for it. I have a fix
that I am testing.
llvm-svn: 127660
|
| |
|
|
| |
llvm-svn: 127659
|
| |
|
|
| |
llvm-svn: 127657
|
| |
|
|
| |
llvm-svn: 127656
|
| |
|
|
|
|
|
|
| |
macro, alias of __attribute__.
On mingw without -fms-extensions, we can provide "as-is" __declspec.
llvm-svn: 127655
|
| |
|
|
|
|
| |
provided as macro by <malloc.h>.
llvm-svn: 127654
|
| |
|
|
|
|
| |
x86_64-w64-mingw32.
llvm-svn: 127652
|
| |
|
|
|
|
| |
of pointers in an std::map.
llvm-svn: 127650
|
| |
|
|
|
|
| |
zext(undef) = 0, because the top bits will be zero.
llvm-svn: 127649
|
| |
|
|
| |
llvm-svn: 127648
|
| |
|
|
|
|
|
|
| |
VEX prefixes are working for triadic AVX
instructions. This concludes the patch set to
enable AVX support for the X86 disassebler.
llvm-svn: 127647
|
| |
|
|
|
|
|
|
| |
in the instruction tables and fixed a few bugs that
were causing decode conflicts. Rudimentary tests
are coming up in the next patch.
llvm-svn: 127646
|
| |
|
|
|
|
|
|
|
| |
instruction set. This code adds support for the VEX prefix
and for the YMM registers accessible on AVX-enabled
architectures. Instruction table support that enables AVX
instructions for the disassembler is in an upcoming patch.
llvm-svn: 127644
|
| |
|
|
|
|
|
| |
This function performed acrobatics to prove no-self-wrap, which we now
have for free.
llvm-svn: 127643
|
| |
|
|
|
|
|
|
|
|
| |
because an extra
register operand was erroneously added. Remove an incorrect assert which triggers the bug.
rdar://problem/9131529
llvm-svn: 127642
|
| |
|
|
|
|
|
|
| |
replace some uses of FieldOffsetInBytes. The remaining uses of
FieldOffsetInBytes will be replaced once NextFieldOffsetInBytes is converted
to CharUnits. No change in functionality intended.
llvm-svn: 127641
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
and then go kablooie. The problem was that it was tracking the PHI nodes anew
each time into this function. But it didn't need to. And because the recursion
didn't know that a PHINode was visited before, it would go ahead and call
itself.
There is a testcase, but unfortunately it's too big to add. This problem will go
away with the EH rewrite.
<rdar://problem/8856298>
llvm-svn: 127640
|
| |
|
|
|
|
|
|
| |
After the open+fstat optimization, files were already opened for FileManager::getBufferForFile() and we closed them after reading them.
The problem was that when -working-directory was passed, the code path that actually reuses & closes the already opened file descriptor
was not followed.
llvm-svn: 127639
|
| |
|
|
|
|
| |
This needs review.
llvm-svn: 127638
|
| |
|
|
|
|
|
| |
Also more cleanly separate the ARM vs. Thumb functionality. Previously, the
encoding would be incorrect for some Thumb instructions (the indirect calls).
llvm-svn: 127637
|
| |
|
|
|
|
|
|
| |
normal version.
Fixes rdar://9123638
llvm-svn: 127636
|
| |
|
|
|
|
| |
The tests fail in a -Asserts build.
llvm-svn: 127635
|
| |
|
|
| |
llvm-svn: 127634
|
| |
|
|
|
|
| |
later forward declared as a struct)
llvm-svn: 127632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
can. As Nate pointed out, VTBL isn't super performant, but it *has* to be better
than this:
_shuf:
@ BB#0: @ %entry
push {r4, r7, lr}
add r7, sp, #4
sub sp, #12
mov r4, sp
bic r4, r4, #7
mov sp, r4
mov r2, sp
vmov d16, r0, r1
orr r0, r2, #6
orr r3, r2, #7
vst1.8 {d16[0]}, [r3]
vst1.8 {d16[5]}, [r0]
subs r4, r7, #4
orr r0, r2, #5
vst1.8 {d16[4]}, [r0]
orr r0, r2, #4
vst1.8 {d16[4]}, [r0]
orr r0, r2, #3
vst1.8 {d16[0]}, [r0]
orr r0, r2, #2
vst1.8 {d16[2]}, [r0]
orr r0, r2, #1
vst1.8 {d16[1]}, [r0]
vst1.8 {d16[3]}, [r2]
vldr.64 d16, [sp]
vmov r0, r1, d16
mov sp, r4
pop {r4, r7, pc}
The "illegal" testcase in vext.ll is no longer illegal.
<rdar://problem/9078775>
llvm-svn: 127630
|
| |
|
|
|
|
|
|
| |
doesn't return, so just go back to using the old runtime function instead
of trying to use abort() when __builtin_unreachable (or an equivalent) isn't
supported.
llvm-svn: 127629
|
| |
|
|
|
|
| |
but it re-organizes the old features, so I can insert the MetadataEngine to use the same infrastructure.
llvm-svn: 127627
|
| |
|
|
|
|
| |
function.
llvm-svn: 127626
|
| |
|
|
|
|
| |
much to be useful.
llvm-svn: 127625
|
| |
|
|
| |
llvm-svn: 127624
|
| |
|
|
|
|
|
|
|
| |
cannot yet be resolved, be sure to push the new label declaration into
the right place within the identifier chain. Otherwise, name lookup in
C++ gets confused when searching for names that are lexically closer
than the label. Fixes PR9463.
llvm-svn: 127623
|
| |
|
|
|
|
| |
the new linker.
llvm-svn: 127622
|