| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Mips (MicroMips) specific STO handling .
The st_other field settig for STO_MIPS_MICROMIPS
Contributer: Zoran Jovanovic
llvm-svn: 175564
|
| |
|
|
| |
llvm-svn: 175562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Generic STO handling at the Target level.
The st_other field of the ELF symbol table is one
byte in size. The first 2 bytes are used for generic
visibility and are currently handled by llvm.
The other six bits are processor specific and need
to be set at the target level.
A couple of notes:
The new static methods for accessing and setting the "other"
flags in include/llvm/MC/MCELF.h match the style guide
and not the other methods in the file. I don't like the
inconsistency, but feel I should follow the prescribed
lowerUpper() convention.
STO_ value definitions are not specified in gnu land as
consistently as the STT_ and STB_ fields. Probably because
the latter were defined in a standards doc and the former
defined partially in code. I have stuck with the full byte
definition of the flags.
Contributer: Zoran Jovanovic
llvm-svn: 175561
|
| |
|
|
| |
llvm-svn: 175560
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In my previous commit:
"Merge a f32 bitcast of a v2i32 extractelt
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers."
I added a pattern containing a copy_to_regclass. The copy_to_regclass is
actually not needed.
radar://13191881
llvm-svn: 175555
|
| |
|
|
|
|
|
|
| |
considered as instructions with side effects.
rdar://13227456
llvm-svn: 175553
|
| |
|
|
|
|
| |
so we cant deref it.
llvm-svn: 175550
|
| |
|
|
|
|
| |
character devices.
llvm-svn: 175549
|
| |
|
|
|
|
|
|
|
|
| |
/dev/stdin as an input when stdin is connected to a tty, for example.
No test, because it's difficult to write a reasonably portable test
for this. /dev/stdin isn't a character device when stdin is redirected
from a file or connected to a pipe.
llvm-svn: 175542
|
| |
|
|
|
|
|
|
|
| |
When creating an allocation hint for a register pair, make sure the hint
for the physical register reference is still in the allocation order.
rdar://13240556
llvm-svn: 175541
|
| |
|
|
|
|
|
|
|
|
| |
Target implementations of getRegAllocationHints() should use the
provided allocation order, and they can never return hints outside the
order. This is already documented in TargetRegisterInfo.h.
<rdar://problem/13240556>
llvm-svn: 175540
|
| |
|
|
|
|
| |
HexagonInstrFormats.td.
llvm-svn: 175537
|
| |
|
|
|
|
| |
No intended functionality change.
llvm-svn: 175536
|
| |
|
|
|
|
| |
PPCJITInfo.cpp in r175394.
llvm-svn: 175531
|
| |
|
|
|
|
|
|
|
|
|
| |
Due to the execution order of doFinalization functions, the GC information were
deleted before AsmPrinter::doFinalization was executed. Thus, the
GCMetadataPrinter::finishAssembly was never called.
The patch fixes that by moving the code of the GCInfoDeleter::doFinalization to
Printer::doFinalization.
llvm-svn: 175528
|
| |
|
|
| |
llvm-svn: 175527
|
| |
|
|
| |
llvm-svn: 175525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers.
The patch fixes this by using a COPY_TO_REGCLASS and a EXTRACT_SUBREG to extract
the element from the vector instead.
radar://13191881
llvm-svn: 175520
|
| |
|
|
|
| |
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175519
|
| |
|
|
|
|
|
|
| |
This stops the Machine Verifier from complaining about uses of undefined
physical registers.
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175518
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kernel function arguments are lowered to loads from the PARAM_I address
space. When creating these load instructions, we were initializing
their MachinePointerInfo with an Arguement object that was not attached
to any function. This was causing the MachineScheduler to crash when
it tried to access the parent of the Arguement.
This has been fixed by initializing the MachinePointerInfo with a
UndefValue instead.
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175517
|
| |
|
|
|
|
|
|
|
| |
In some cases, we were losing track of live implicit registers which
was creating dead defs and causing the scheduler to produce invalid
code.
NOTE: This is a candidate for the Mesa stable branch.
llvm-svn: 175516
|
| |
|
|
|
|
| |
is explicitly called during module initialization of lib/Support/Process.cpp. It reads the field of global object PosixZeroTime, which is not guaranteed to be initialized at this point. Found by AddressSanitizer with -fsanitize=init-order option.
llvm-svn: 175509
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes asan instrument memory accesses with unusual sizes (e.g. 5 bytes or 10 bytes), e.g. long double or
packed structures.
Instrumentation is done with two 1-byte checks
(first and last bytes) and if the error is found
__asan_report_load_n(addr, real_size) or
__asan_report_store_n(addr, real_size)
is called.
Also, call these two new functions in memset/memcpy
instrumentation.
asan-rt part will follow.
llvm-svn: 175507
|
| |
|
|
| |
llvm-svn: 175501
|
| |
|
|
| |
llvm-svn: 175497
|
| |
|
|
| |
llvm-svn: 175490
|
| |
|
|
| |
llvm-svn: 175488
|
| |
|
|
| |
llvm-svn: 175487
|
| |
|
|
|
|
| |
BtnezT8SltiX16, BtnezT8SltiuX16 .
llvm-svn: 175486
|
| |
|
|
|
|
| |
performs.
llvm-svn: 175485
|
| |
|
|
|
|
| |
lookups in collectMarkers.
llvm-svn: 175484
|
| |
|
|
|
|
|
|
|
|
| |
fields were only ever set in the constructor. The create method retains
its consistent interface so that these bits can be re-threaded through
the emitter if they're ever needed.
This was found by the -Wunused-private-field Clang warning.
llvm-svn: 175482
|
| |
|
|
| |
llvm-svn: 175476
|
| |
|
|
| |
llvm-svn: 175474
|
| |
|
|
| |
llvm-svn: 175472
|
| |
|
|
|
|
| |
library call.
llvm-svn: 175470
|
| |
|
|
| |
llvm-svn: 175467
|
| |
|
|
|
|
|
| |
Also removes some redundant DNI comments on function declarations already
using the macro.
llvm-svn: 175466
|
| |
|
|
| |
llvm-svn: 175464
|
| |
|
|
| |
llvm-svn: 175463
|
| |
|
|
|
|
|
|
| |
If the memcpy has an odd length with an alignment of 2, this would incorrectly
assert on the last 1 byte copy.
rdar://13202135
llvm-svn: 175459
|
| |
|
|
| |
llvm-svn: 175458
|
| |
|
|
| |
llvm-svn: 175457
|
| |
|
|
| |
llvm-svn: 175456
|
| |
|
|
| |
llvm-svn: 175446
|
| |
|
|
|
|
|
| |
NOTE: This is a candidate for the Mesa stable branch.
Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
llvm-svn: 175445
|
| |
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
llvm-svn: 175443
|
| |
|
|
|
|
| |
long double will require a more general solution
llvm-svn: 175442
|
| |
|
|
|
|
|
| |
Currently we're at 34. Bitset should compile into virtually the same code as
uint64_t here.
llvm-svn: 175437
|