| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This should simplify the subtarget definitions and make it easier to
add new ones.
Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183566
|
| |
|
|
|
|
|
|
| |
the internals of TargetMachine could change.
No functionality change intended.
llvm-svn: 183565
|
| |
|
|
|
|
|
|
| |
the internals of TargetMachine could change.
No functionality change intended.
llvm-svn: 183561
|
| |
|
|
|
|
|
|
| |
Reviewed-by: Vincent Lejeune <vljn@ovi.com>
https://bugs.freedesktop.org/show_bug.cgi?id=64257
llvm-svn: 183560
|
| |
|
|
|
|
|
| |
This is the convention used by the other targets.
Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183559
|
| |
|
|
|
| |
Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183558
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.
The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>
llvm-svn: 183552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My recent ARM FastISel patch exposed this bug:
http://llvm.org/bugs/show_bug.cgi?id=16178
The root cause is that it can't select integer sext/zext pre-ARMv6 and
asserts out.
The current integer sext/zext code doesn't handle other cases gracefully
either, so this patch makes it handle all sext and zext from i1/i8/i16
to i8/i16/i32, with and without ARMv6, both in Thumb and ARM mode. This
should fix the bug as well as make FastISel faster because it bails to
SelectionDAG less often. See fastisel-ext.patch for this.
fastisel-ext-tests.patch changes current tests to always use reg-imm AND
for 8-bit zext instead of UXTB. This simplifies code since it is
supported on ARMv4t and later, and at least on A15 both should perform
exactly the same (both have exec 1 uop 1, type I).
2013-05-31-char-shift-crash.ll is a bitcode version of the above bug
16178 repro.
fast-isel-ext.ll tests all sext/zext combinations that ARM FastISel
should now handle.
Note that my ARM FastISel enabling patch was reverted due to a separate
failure when dealing with MCJIT, I'll fix this second failure and then
turn FastISel on again for non-iOS ARM targets.
I've tested "make check-all" on my x86 box, and "lnt test-suite" on A15
hardware.
llvm-svn: 183551
|
| |
|
|
|
|
| |
Found be libstdc's debug mode.
llvm-svn: 183549
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix an assertion when the compiler encounters big constants whose bit width is
not a multiple of 64-bits.
Although clang would never generate something like this, the backend should be
able to handle any legal IR.
<rdar://problem/13363576>
llvm-svn: 183544
|
| |
|
|
|
|
| |
Use the correct DIType when creating types in DIBuilder.
llvm-svn: 183543
|
| |
|
|
|
|
| |
full std::remove.
llvm-svn: 183541
|
| |
|
|
|
|
| |
Thanks to Benjamin Kramer for the suggestion.
llvm-svn: 183540
|
| |
|
|
|
|
| |
I am able to compile/assemble/link/run /bin/echo from FreeBSD.
llvm-svn: 183537
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenBSD's stack smashing protection differs slightly from other
platforms:
1. The smash handler function is "__stack_smash_handler(const char
*funcname)" instead of "__stack_chk_fail(void)".
2. There's a hidden "long __guard_local" object that gets linked
into each executable and DSO.
Patch by Matthew Dempsky.
llvm-svn: 183533
|
| |
|
|
|
|
| |
As a bonus this reduces the loop from O(n^2) to O(n).
llvm-svn: 183532
|
| |
|
|
| |
llvm-svn: 183528
|
| |
|
|
|
|
| |
Avoids unused variable warnings in Release builds.
llvm-svn: 183512
|
| |
|
|
| |
llvm-svn: 183495
|
| |
|
|
|
|
|
|
| |
the internals of TargetMachine could change.
No functionality change intended.
llvm-svn: 183494
|
| |
|
|
|
|
| |
the internals of TargetMachine could change.
llvm-svn: 183493
|
| |
|
|
|
|
| |
the internals of TargetMachine could change.
llvm-svn: 183492
|
| |
|
|
|
|
| |
the internals of TargetMachine could change.
llvm-svn: 183491
|
| |
|
|
|
|
| |
the internals of TargetMachine could change.
llvm-svn: 183490
|
| |
|
|
|
|
|
|
| |
TopDownPathCount/BottomUpPathCount.
rdar://12480535
llvm-svn: 183489
|
| |
|
|
|
|
| |
the internals of TargetMachine could change.
llvm-svn: 183488
|
| |
|
|
|
|
| |
These objects are internal to the TargetMachine object and may change.
llvm-svn: 183485
|
| |
|
|
|
|
| |
Use the correct DIType when creating vector types.
llvm-svn: 183484
|
| |
|
|
| |
llvm-svn: 183477
|
| |
|
|
|
|
| |
Reapply 183271.
llvm-svn: 183472
|
| |
|
|
|
|
|
|
| |
Reapply 183270 again (because three is a magic number).
This should now no longer seg fault after r183459.
llvm-svn: 183464
|
| |
|
|
| |
llvm-svn: 183463
|
| |
|
|
| |
llvm-svn: 183461
|
| |
|
|
| |
llvm-svn: 183458
|
| |
|
|
|
|
| |
compiling chrome. This patch adds a new flag to enable vectorization on all levels and not only on -O3. It should go away once we make a decision.
llvm-svn: 183456
|
| |
|
|
| |
llvm-svn: 183454
|
| |
|
|
|
|
| |
Breaks linux build bots (I thought the problem was something else).
llvm-svn: 183447
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Seems we emit the parameter ordering number (spuriously named 'arg
number') in the debug info, so there's no need to search through the
variable list to figure out the parameter ordering. This implementation
does 'always' do the work, even in non-optimized debug info (the
previous implementation checked the existence of the 'variables' list on
the subprogram which is only present in optimized builds).
No intended functionality change.
llvm-svn: 183446
|
| |
|
|
|
|
| |
Reapply 183270.
llvm-svn: 183445
|
| |
|
|
|
|
| |
Reapply 183269.
llvm-svn: 183441
|
| |
|
|
| |
llvm-svn: 183439
|
| |
|
|
|
|
| |
Reapply 183268.
llvm-svn: 183438
|
| |
|
|
|
|
| |
Reapply 183267.
llvm-svn: 183436
|
| |
|
|
|
|
|
|
| |
Add more InstRW mappings.
Reapply 183266.
llvm-svn: 183435
|
| |
|
|
|
|
| |
Reapply 183265.
llvm-svn: 183432
|
| |
|
|
|
|
| |
Reapply 183264.
llvm-svn: 183430
|
| |
|
|
|
|
| |
Reapply 183263.
llvm-svn: 183428
|
| |
|
|
|
|
| |
Reapply 183262.
llvm-svn: 183427
|
| |
|
|
|
|
| |
Reapply 183261.
llvm-svn: 183425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from the LC_DATA_IN_CODE load command. And when disassembling print
the data in code formatted for the kind of data it and not disassemble those
bytes.
I added the format specific functionality to the derived class MachOObjectFile
since these tables only appears in Mach-O object files. This is my first
attempt to modify the libObject stuff so if folks have better suggestions
how to fit this in or suggestions on the implementation please let me know.
rdar://11791371
llvm-svn: 183424
|