Revert r288447 which introduced -mdirect. It turns out we don't need a
custom flag for this, as the information we need is in the target triple.
llvm-svn: 288604
lib/Target/AMDGPU/SIRegisterInfo.cpp: In member function 'void llvm::SIRegisterInfo::spillSGPR(llvm::MachineBasicBlock::iterator, int, llvm::RegScavenger*) const':
lib/Target/AMDGPU/SIRegisterInfo.cpp:572:30: warning: variable 'SubRC' set but not used [-Wunused-but-set-variable]
const TargetRegisterClass *SubRC = nullptr;
^
lib/Target/AMDGPU/SIRegisterInfo.cpp: In member function 'void llvm::SIRegisterInfo::restoreSGPR(llvm::MachineBasicBlock::iterator, int, llvm::RegScavenger*) const':
lib/Target/AMDGPU/SIRegisterInfo.cpp:723:30: warning: variable 'SubRC' set but not used [-Wunused-but-set-variable]
const TargetRegisterClass *SubRC = nullptr;
^
The variable was assigned to, but never used. The functions called did not
mutate state. Simplify the logic and remove the variable. Identified by gcc
5.4.0.
llvm-svn: 288601
Add an optional parameter to `llvm_install_symlink` which allows the symlink
installation to be placed into a specific component rather than the default
value.
llvm-svn: 288600
Summary:
"Lookup" is a noun ("lookup table"), "look up" is a verb ("look up
'table' in the dictionary").
Reviewers: chandlerc
Subscribers: silvas, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D27374
llvm-svn: 288598
Summary:
Previously in AnalysisManager::invalidate(), we would walk the full
ResultsList even if we knew that nothing was invalidated.
Reviewers: chandlerc
Subscribers: silvas, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D27371
llvm-svn: 288595
Summary:
Previously, we were forcing a copy if you passed an lvalue argument; now
we'll take it by reference.
Reviewers: chandlerc
Subscribers: mehdi_amini, silvas, llvm-commits
Differential Revision: https://reviews.llvm.org/D27370
llvm-svn: 288594
Some elf producers (dtrace) put this flag in relocation sections and
some (MC) don't. If we don't ignore the flag we end up with multiple
relocation sections poiting to the same section, which we don't
support.
llvm-svn: 288585
This solves a secondary problem seen in PR6137:
https://llvm.org/bugs/show_bug.cgi?id=6137#c6
This is similar to the bitwise logic op fold added with:
https://reviews.llvm.org/rL287707
And like that patch, I'm artificially restricting the
transform from vector <-> scalar types until we're sure
that the backend can handle that.
llvm-svn: 288584
A program or object file using R_386_8, R_386_16, R_386_PC16 or R_386_PC8
relocations is not conformant to latest ABI. The R_386_16, and R_386_8
relocations truncate the computed value to 16 - bits and 8 - bits
respectively. R_386_PC16 and R_386_16 are used by some
applications, for example by FreeBSD loaders.
Previously we did not take addend in account for these relocation,
counting it as 0, what is wrong and was a reason of hangs.
This patch needed for example for FreeBSD pmbr (protective mbr).
Differential revision: https://reviews.llvm.org/D27303
llvm-svn: 288581
Binary output feature is a bit confuzing. bfd and gold output differs a lot sometimes,
though it is important for FreeBSD mbr loaders.
Patch change the way how we compute file offsets for binary output.
This fixes PR31196.
Previously offsets were calculated basing on offsets and addresses of sections
from the same loads:
if (Sec == First)
return alignTo(Off, Target->MaxPageSize, Sec->Addr);
return First->Offset + Sec->Addr - First->Addr;
bfd assigns offsets for each section to VA - MinVA:
https://github.com/redox-os/binutils-gdb/blob/master/bfd/binary.c#L27https://github.com/redox-os/binutils-gdb/blob/master/bfd/binary.c#L255
(LMA == VA usually)
This patch for now just stops creating phdrs for binary output.
An effect from this that no any additional calculation for offset is performed:
uintX_t getFileAlignment(uintX_t Off, OutputSectionBase *Sec) {
OutputSectionBase *First = Sec->FirstInPtLoad;
// If the section is not in a PT_LOAD, we have no other constraint.
if (!First)
return Off; //**First is always null, condition always happens**
That is enough now with combination of another patch to generate output
that is similar to what bfd produce for mbr loader.
Differential revision: https://reviews.llvm.org/D27341
llvm-svn: 288580
--omagic is an option to create old-fashioned executables in which
.text segments are writable. Today, the option is still in use to
create special-purpose programs such as boot loaders. It doesn't
make sense to create PT_GNU_RELRO for such executables.
DIfferential revision: https://reviews.llvm.org/D27297
llvm-svn: 288579
An explicit template specialization can cause the implicit template
specialization of a type which inherits the attributes. In such a case, we
would end up with a delayed template specialization for a dll exported type
which we would fail to reference. This would trigger an assertion.
We now propagate the dll storage attributes through the inheritance
chain. Only after having done so do we reference the delayed template
specializations. This allows any implicit specializations which inherit dll
storage to also be referenced.
llvm-svn: 288570
Summary:
The C++17 rules for aggregate initialization changed to disallow types with explicit constructors [dcl.init.aggr]p1. This patch implements that new rule.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25654
llvm-svn: 288565
Previously this pass was using up to 5% compile time in some cases which
is a bit much for what it is doing. The pass featured a full blown
data-flow analysis which in the default configuration was restricted to a
single block.
This rewrites the pass under the assumption that we only ever work on a
single block. This is done in a single pass maintaining a state machine
per general purpose register to catch LOH patterns.
Differential Revision: https://reviews.llvm.org/D27329
llvm-svn: 288561
VSX has instructions lxsiwax/lxsdx that can load 32/64 bit value into VSX register cheaply. That patch makes it known to memory cost model, so the vectorization of the test case in pr30990 is beneficial.
Differential Revision: https://reviews.llvm.org/D26713
llvm-svn: 288560
Rui Ueyama