The .even directive aligns content to an evan-numbered address. This is an ARM
specific directive applicable to any section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198031 91177308-0d34-0410-b5e6-96231b3b80d8
E.g. the codegen result is
fmls v1.2s, v0.2s, v2.s[3]
which is expected to be
fmls v0.2s, v1.2s, v2.s[3]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198001 91177308-0d34-0410-b5e6-96231b3b80d8
...namely LOAD AND ADD, LOAD AND AND, LOAD AND OR and LOAD AND EXCLUSIVE OR.
LOAD AND ADD LOGICAL isn't really separately useful for LLVM.
I'll look at adding reusing the CC results in new year.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197985 91177308-0d34-0410-b5e6-96231b3b80d8
DAG.getVectorShuffle() doesn't always return a vector_shuffle node.
If mask is the exact sequence of it's operand(For example, operand_0
is v8i8, and the mask is 0, 1, 2, 3, 4, 5, 6, 7), it will directly
return that operand. So a check is added here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197967 91177308-0d34-0410-b5e6-96231b3b80d8
This failure caused by improper condition when lowering shuffle_vector
to scalar_to_vector. After this patch NEON_VDUP with v1i64 will not
be generated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197966 91177308-0d34-0410-b5e6-96231b3b80d8
Check for single use of fmul node in fused multiply patterns
to allow generation of fused multiply add/sub instructions.
Otherwise fmul operation ends up being repeated more than
once which does not help peformance on targets with
only one MAC unit, as for example cortex-a53.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197929 91177308-0d34-0410-b5e6-96231b3b80d8
The correct pattern matching should be:
- fnmadd is (-Ra) + (-Rn)*Rm which should be matched as:
fma (fneg node:$Rn), node:$Rm, (fneg node:$Ra) and as
(f32 (fsub (f32 (fneg FPR32:$Ra)), (f32 (fmul FPR32:$Rn, FPR32:$Rm))))
- fnmsub is (-Ra) + Rn*Rm which should be matched as
fma node:$Rn, node:$Rm, (fneg node:$Ra) and as
(f32 (fsub (f32 (fmul FPR32:$Rn, FPR32:$Rm)), FPR32:$Ra))))
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197928 91177308-0d34-0410-b5e6-96231b3b80d8
Split sadd.with.overflow into add + sadd.with.overflow to allow
analysis and optimization. This should ideally be done after
InstCombine, which can perform code motion (eventually indvars should
run after all canonical instcombines). We want ISEL to recombine the
add and the check, at least on x86.
This is currently under an option for reducing live induction
variables: -liv-reduce. The next step is reducing liveness of IVs that
are live out of the overflow check paths. Once the related
optimizations are fully developed, reviewed and tested, I do expect
this to become default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197926 91177308-0d34-0410-b5e6-96231b3b80d8
(optional) DWARF sections, so compiling with -g does not result in
different code being generated.
rdar://problem/15623193
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197922 91177308-0d34-0410-b5e6-96231b3b80d8
The bkpt mnemonic has an implicit immediate constant of 0 unless otherwise
specified. Add an instruction alias for the unvalued breakpoint mnemonic to
treat it as a 0. This improves compatibility with GNU AS.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197913 91177308-0d34-0410-b5e6-96231b3b80d8
If the Scalarizer scalarized a vector PHI but could not scalarize
all uses of it, it would insert a series of insertelements to reconstruct
the vector PHI value from the scalar ones. The problem was that it would
emit these insertelements immediately after the PHI, even if there were
other PHIs after it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197909 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Before this change the instrumented code before Ret instructions looked like:
<Unpoison Frame Redzones>
if (Frame != OriginalFrame) // I.e. Frame is fake
<Poison Complete Frame>
Now the instrumented code looks like:
if (Frame != OriginalFrame) // I.e. Frame is fake
<Poison Complete Frame>
else
<Unpoison Frame Redzones>
Reviewers: eugenis
Reviewed By: eugenis
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2458
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197907 91177308-0d34-0410-b5e6-96231b3b80d8
Backends like OptParserEmitter assume that record names can be used as valid
identifiers.
The period '.' in generated anonymous names broke that assumption, causing a
build-time error and in practice forcing all records to be named.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197869 91177308-0d34-0410-b5e6-96231b3b80d8
If the extension of a loaded value is compared against zero and used in
other arithmetic, InstCombine will change the comparison to use the
unextended load. It's also possible that the comparison could be against
the unextended load from the outset.
In DAG form this becomes a truncation of an extending load. We want to
strip the truncation if possible so that we can use load-and-test instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197804 91177308-0d34-0410-b5e6-96231b3b80d8
The handling of ANY_EXTEND and ZERO_EXTEND was too strict. In this context
we can treat ZERO_EXTEND in much the same way as an AND and then also handle
outermost ZERO_EXTENDs.
I couldn't find a test that benefited from the ANY_EXTEND change, but it's
more obvious to write it this way once SIGN_EXTEND and ZERO_EXTEND are
handled differently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197802 91177308-0d34-0410-b5e6-96231b3b80d8
Recently, support for krait cpu was added. This commit extends getHostCPUName()
to return krait as cpu for the APQ8064 (a Krait 300).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197792 91177308-0d34-0410-b5e6-96231b3b80d8
If we happen to eliminate every case in a switch that has branch
weights, we currently try to create metadata for the one remaining
branch, triggering an assert. Instead, we need to check that the
metadata we're trying to create is sensible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197791 91177308-0d34-0410-b5e6-96231b3b80d8
The .pool directive is an alias for the .ltorg directive used to create a
literal pool. Simply treat .pool as if .ltorg was passed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197787 91177308-0d34-0410-b5e6-96231b3b80d8
v2: Add ftrunc->TRUNC pattern instead of replacing int_AMDGPU_trunc
v3: move ftrunc pattern next to TRUNC definition, it's available since R600
Patch By: Jan Vesely
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197783 91177308-0d34-0410-b5e6-96231b3b80d8
when you want to have the full list of addresses for a particular CU or
when you have multiple modules linked together and can't depend upon the
ordering of a single CU for begin/end ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197776 91177308-0d34-0410-b5e6-96231b3b80d8
That's what it actually means, and with 16-bit support it's going to be
a little more relevant since in a few corner cases we may actually want
to distinguish between 16-bit and 32-bit mode (for example the bare 'push'
aliases to pushw/pushl etc.)
Patch by David Woodhouse
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197768 91177308-0d34-0410-b5e6-96231b3b80d8
this commit as the only one on the Blamelist so I quickly reverted this.
However it was actually Nick's change who has since fixed that issue.
Original commit message:
Changed the X86 assembler for intel syntax to work with directional labels.
The X86 assembler as a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand(). This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.
The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following an Integer. Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels. It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.
When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.
rdar://14961158
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197744 91177308-0d34-0410-b5e6-96231b3b80d8
I have a pending change for clang to use getStringRepresentation to check
that its DataLayout is in sync with llvm's.
getStringRepresentation is not called from llvm itself, so far it is mostly
a debugging aid, so the shorter strings are an independent improvement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197740 91177308-0d34-0410-b5e6-96231b3b80d8
We dump any non-empty assembler constant pools after a successful
parse of an assembly file that uses the ldr pseudo opcode. These
per-section constant pools should be output in a deterministic order
to ensure that we always generate the same output when printing the
output with an AsmStreamer.
This patch changes the map data struture used to associate a section
with its constant pool to a MapVector to ensure deterministic
output. Because this map type does not support deletion, we now
check that the constant pool is not empty before dumping its entries
and clear the entries after emitting them with the streamer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197735 91177308-0d34-0410-b5e6-96231b3b80d8
The X86 assembler has a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand(). This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.
The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following the Integer. Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels. It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.
When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.
rdar://14961158
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197728 91177308-0d34-0410-b5e6-96231b3b80d8
According to the docs, ThreadLocal<>::get() should return NULL
if no object has been set. This patch makes that the case also for non-thread
builds and adds a very basic unit test to check it.
(This was causing PR18205 because PrettyStackTraceHead didn't get zero-
initialized and we'd crash trying to read past the end of that list. We didn't
notice this so much on Linux since we'd crash after printing all the entries,
but on Mac we print into a SmallString, and would crash before printing that.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197718 91177308-0d34-0410-b5e6-96231b3b80d8
The condition in selects is supposed to be i1.
Make sure we are just reading the less significant bit
of the 8 bits width value to match this constraint.
<rdar://problem/15651765>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197712 91177308-0d34-0410-b5e6-96231b3b80d8
This directive will write out the assembler-maintained constant
pool for the current section. These constant pools are created to
support the ldr-pseudo instruction (e.g. ldr r0, =val).
The directive can be used by the programmer to place the constant
pool in a location that can be reached by a pc-relative offset in
the ldr instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197711 91177308-0d34-0410-b5e6-96231b3b80d8
The ldr-pseudo opcode is a convenience for loading 32-bit constants.
It is converted into a pc-relative load from a constant pool. For
example,
ldr r0, =0x10001
ldr r1, =bar
will generate this output in the final assembly
ldr r0, .Ltmp0
ldr r1, .Ltmp1
...
.Ltmp0: .long 0x10001
.Ltmp1: .long bar
Sketch of the LDR pseudo implementation:
Keep a map from Section => ConstantPool
When parsing ldr r0, =val
parse val as an MCExpr
get ConstantPool for current Section
Label = CreateTempSymbol()
remember val in ConstantPool at next free slot
add operand to ldr that is MCSymbolRef of Label
On finishParse() callback
Write out all non-empty constant pools
for each Entry in ConstantPool
Emit Entry.Label
Emit Entry.Value
Possible improvements to be added in a later patch:
1. Does not convert load of small constants to mov
(e.g. ldr r0, =0x1 => mov r0, 0x1)
2. Does reuse constant pool entries for same constant
The implementation was tested for ARM, Thumb1, and Thumb2 targets on
linux and darwin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197708 91177308-0d34-0410-b5e6-96231b3b80d8
This callback is invoked when the parse has finished successfuly. It
will be used to write out ARM constant pools to implement the ldr
pseudo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197706 91177308-0d34-0410-b5e6-96231b3b80d8
This change fixes the case of arithmetic shift right - do not attempt to fold that case.
This change also relaxes the conditions when attempting to fold the logical shift right and shift left cases.
No additional IR-level test cases included at this time. See http://llvm.org/bugs/show_bug.cgi?id=17827 for proofs that these are correct transformations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197705 91177308-0d34-0410-b5e6-96231b3b80d8
The tests for the disassembler were adapted from the encoder tests, and for the
most part, the output from the disassembler matches that encoder-test inputs.
There are some places where more-informative mnemonics could be produced
(notably for the branch instructions), and those cases are noted in the tests
with FIXMEs.
Future work includes:
- Generating more-informative mnemonics when possible (this may also be done
in the printer).
- Remove the dependence on positional "numbered" operand-to-variable mapping
(for both encoding and decoding).
- Internally using 64-bit instruction variants in 64-bit mode (if this turns
out to matter).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197693 91177308-0d34-0410-b5e6-96231b3b80d8
Currently SplitBlockAndInsertIfThen requires that branch condition is an
Instruction itself, which is very inconvenient, because it is sometimes an
Operator, or even a Constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197677 91177308-0d34-0410-b5e6-96231b3b80d8
Different sized address spaces should theoretically work
most of the time now, and since 64-bit add is currently
disabled, using more 32-bit pointers fixes some cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197659 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the .inst directive. This is an ARM specific directive to
indicate an instruction encoded as a constant expression. The major difference
between .word, .short, or .byte and .inst is that the latter will be
disassembled as an instruction since it does not get flagged as data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197657 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the MachineFrameInfo API to use the new SSPLayoutKind information
produced by the StackProtector pass (instead of a boolean flag) and updates a
few pass dependencies (to preserve the SSP analysis).
The stack layout follows the same approach used prior to this change - i.e.,
only LargeArray stack objects will be placed near the canary and everything
else will be laid out normally. After this change, structures containing large
arrays will also be placed near the canary - a case previously missed by the
old implementation.
Out of tree targets will need to update their usage of
MachineFrameInfo::CreateStackObject to remove the MayNeedSP argument.
The next patch will implement the rules for sspstrong and sspreq. The end goal
is to support ssp-strong stack layout rules.
WIP.
Differential Revision: http://llvm-reviews.chandlerc.com/D2158
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197653 91177308-0d34-0410-b5e6-96231b3b80d8
This matches the data in clang which was added by Jakob Stoklund Olesen in
r179596.
Thanks for erikjv on irc for pointing me to the relevant documents:
http://sparc.com/standards/64.psabi.1.35.ps.Z
page 25: Every stack frame must be 16-byte aligned.
http://sparc.com/standards/psABI3rd.pdf
page 3-10: Although the architecture requires only word alignment, software convention and the operating system require every stack frame to be doubleword aligned.
I tried to add a test, but it looks like sparc doesn't implement dynamic stack
realignment. This will be tested in clang shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197646 91177308-0d34-0410-b5e6-96231b3b80d8
The inalloca attribute is designed to support passing C++ objects by
value in the Microsoft C++ ABI. It behaves the same as byval, except
that it always implies that the argument is in memory and that the bytes
are never copied. This attribute allows the caller to take the address
of an outgoing argument's memory and execute arbitrary code to store
into it.
This patch adds basic IR support, docs, and verification. It does not
attempt to implement any lowering or fix any possibly broken transforms.
When this patch lands, a complete description of this feature should
appear at http://llvm.org/docs/InAlloca.html .
Differential Revision: http://llvm-reviews.chandlerc.com/D2173
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197645 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to the file summaries, the function summaries output line,
branching and call statistics. The file summaries have been moved
outside the initial loop so that all of the function summaries can be
outputted before file summaries.
Also updated test cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197633 91177308-0d34-0410-b5e6-96231b3b80d8
tail call optimization. Some more work may be needed for indirect
calls but this patch fixes the current regression in Prolangc++/trees.
S2 optimization as part of the general cleanup and optimization
of prolog and epilog was not saving S2 in this case and needed to.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197630 91177308-0d34-0410-b5e6-96231b3b80d8
Given vsel_cc, op1, op2, since vsel has no LE/LT, to generate vsel for
such selection, it needs to inverse cc and swap op1 and op2. To inverse
cc, both L/G and E bits should be flipped.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197615 91177308-0d34-0410-b5e6-96231b3b80d8
File summaries will now be optionally outputted which will give line,
branching and call coverage info. Unfortunately, clang's current
instrumentation does not give enough information to deduce function
calls, something that gcc is able to do. Thus, no calls are always
outputted to be consistent with gcov output.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197606 91177308-0d34-0410-b5e6-96231b3b80d8
This will cause llvm-cov to output branch counts instead of branch
probabilities. -b must be enabled.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197594 91177308-0d34-0410-b5e6-96231b3b80d8
According to "Addenda to ABI for ARM architecture", Tag_FP_arch is the
new name for the equivalent Tag_VFP_arch. This commit renames
Tag_VFP_arch to Tag_FP_arch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197587 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds -f64:32:64 to 32 bit ppc darwin since a f64 inside a
structure are only 32 bit aligned.
The patch also drop -f128:64:128 from all ppc darwin, since f128 is
128 bit aligned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197574 91177308-0d34-0410-b5e6-96231b3b80d8
Clang sets the float-abi target option manually, but no longer
annotates each function with its ABI. This can lead to confusing
mistmatch between "clang -emit-llvm | llc" and normal clang
invocations.
Besides which, gnueabihf actually *is* hard-float. Defaulting to soft
was just perverse.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197554 91177308-0d34-0410-b5e6-96231b3b80d8
The .end directive indicates the end of the file. No further instructions are
processed after a .end directive is encountered.
One potential (glaringly obvious) optimisation that could be pursued here is to
extend MCAsmParser with a DiscardRemainder method to avoid processing lexemes to
the end of the file. It was unclear at this point if that would be worth
adding, and could easily be added in a follow on change.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197547 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies type unit and type unit reference creation as well as
setting the stage for inter-type hashing across type unit boundaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197539 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the "n" and "S" components of the data layout for mips. Clang
already gets this right.
This will be tested in clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197536 91177308-0d34-0410-b5e6-96231b3b80d8
The instruction definitions in the PPC backend have a number of variants
defined for the same instruction to represent differences between 64-bit and
32-bit semantics. In order to generate a disassembler for the PPC backend, we
need to mark all but one of these as CodeGen only.
No functionality change intended; this is prep work for PPC disassembly
support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197535 91177308-0d34-0410-b5e6-96231b3b80d8
Without this, assembling clang's disassembly would produce an object
file with the IMAGE_SCN_CNT_INITIALIZED_DATA section characteristic
rather than the uninitialized one. link.exe would warn when merging
comdats with different flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197529 91177308-0d34-0410-b5e6-96231b3b80d8
This effectively backs out r197465 but leaves some of the general
fixes in place. Not all targets are ready to handle this feature. To
enable it, some infrastructure work is needed to better handle
register class constraints.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197514 91177308-0d34-0410-b5e6-96231b3b80d8
This reapplies r197438 and fixes the link-time circular dependency between
IR and Support. The fix consists in moving the diagnostic support into IR.
The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.
This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.
This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).
This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.
http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197508 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r197481, recommiting r197469 with an extra fix.
The vastart_save_xmm_regs pseudo-instruction expands to a test and a
branch, so it modifies EFLAGS. Mark it so, or else the scheduler might
place it in the middle of another test+branch.
This fixes a bug exposed by r192750, which changed the initial scheduler
to source-order as part of enabling the MI Scheduler for X86.
This re-commit changes the VASTART_SAVE_XMM_REGS custom inserter not to
try to save %flags, and adds a test that catches the bad behavior of
r197469.
<rdar://problem/15627766>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197503 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/bugs/show_bug.cgi?id=18045
Short issue description:
For X86 machines with sse < sse4.1 we got failures for some
particular load/store vector sequences:
$ clang-trunk -m32 -O2 test-case.c
fatal error: error in backend: Cannot select: 0x4200920: v4i32,ch = load 0x41d6ab0, 0x4205850,
0x41dcb10<LD16[getelementptr inbounds ([4 x i32]* @e, i32 0, i32 0)](align=4)> [ORD=82]
[ID=58]
0x4205850: i32 = X86ISD::Wrapper 0x41d5490 [ORD=26] [ID=43]
0x41d5490: i32 = TargetGlobalAddress<[4 x i32]* @e> 0 [ORD=26] [ID=23]
0x41dcb10: i32 = undef [ID=2]
The reason is that EltsFromConsecutiveLoads could emit such load instruction
both before and after legalize stage. Though this instruction is not legal for
machines with SSSE3 and lower.
The fix: In EltsFromConsecutiveLoads, if we have passed legalize stage, we
check whether nodes it emits are legal.
P.S.: If you get failure in time from 12:00 and till 22:00 (UTC-8),
perhaps I'll slow with response, so you better reject this commit. Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197492 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r197469.
The sanitizer and dragonegg buildbots are failing, I think because of
this change. Reverting until I figure out why.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197481 91177308-0d34-0410-b5e6-96231b3b80d8
The vastart_save_xmm_regs pseudo-instruction expands to a test and a
branch, so it modifies EFLAGS. Mark it so, or else the scheduler might
place it in the middle of another test+branch.
This fixes a bug exposed by r192750, which turned on the MI Scheduler
for X86.
<rdar://problem/15627766>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197469 91177308-0d34-0410-b5e6-96231b3b80d8
Without this, MachineCSE is powerless to handle redundant operations with truncated source operands.
This required fixing the 2-addr pass to handle tied subregisters. It isn't clear what combinations of subregisters can legally be tied, but the simple case of truncated source operands is now safely handled:
%vreg11<def> = COPY %vreg1:sub_32bit; GR32:%vreg11 GR64:%vreg1
%vreg12<def> = COPY %vreg2:sub_32bit; GR32:%vreg12 GR64:%vreg2
%vreg13<def,tied1> = ADD32rr %vreg11<tied0>, %vreg12<kill>, %EFLAGS<imp-def>
Test case: cse-add-with-overflow.ll.
This exposed an existing bug in
PPCInstrInfo::commuteInstruction. Thanks to Rafael for the test case:
PowerPC/crash.ll.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197465 91177308-0d34-0410-b5e6-96231b3b80d8
Re-reading the comment I updated in previous commit, it's better to make
it more explicit and avoid ambiguity more effectively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197458 91177308-0d34-0410-b5e6-96231b3b80d8
A phi node operand or an instruction operand could be a constant expression that
can trap (division). Check that we don't vectorize such cases.
PR16729
radar://15653590
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197449 91177308-0d34-0410-b5e6-96231b3b80d8
DiagnosticPrinter.cpp.
These was creating a link time dependencies of IR on CodeGen and Analysis.
Part of <rdar://problem/15515174>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197447 91177308-0d34-0410-b5e6-96231b3b80d8
The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.
This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.
This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).
This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.
http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197438 91177308-0d34-0410-b5e6-96231b3b80d8
Outputs branch information for unconditional branches in addition to
conditional branches. -b option must be enabled.
Also updated tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197432 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the WebKit_JS calling convention to perform partial writes on a 4
byte granularity to stack slots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197431 91177308-0d34-0410-b5e6-96231b3b80d8
that it coalesces normal copies.
Without this, MachineCSE is powerless to handle redundant operations
with truncated source operands.
This required fixing the 2-addr pass to handle tied subregisters. It
isn't clear what combinations of subregisters can legally be tied, but
the simple case of truncated source operands is now safely handled:
%vreg11<def> = COPY %vreg1:sub_32bit; GR32:%vreg11 GR64:%vreg1
%vreg12<def> = COPY %vreg2:sub_32bit; GR32:%vreg12 GR64:%vreg2
%vreg13<def,tied1> = ADD32rr %vreg11<tied0>, %vreg12<kill>, %EFLAGS<imp-def>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197414 91177308-0d34-0410-b5e6-96231b3b80d8
Produce them in the same order on every target. The order is that of
getStringRepresentation: e|E-i*-f*-v*-a*-s*-n*-S*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197411 91177308-0d34-0410-b5e6-96231b3b80d8
This was manifesting as an LLVM_ASSUME_ALIGNED() failure in an ELF debug
info test when building LLVM with clang in the Microsoft C++ ABI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197401 91177308-0d34-0410-b5e6-96231b3b80d8
Added scalar compare VCMPSS, VCMPSD.
Implemented LowerSELECT for scalar FP operations.
I replaced FSETCCss, FSETCCsd with one node type FSETCCs.
Node extract_vector_elt(v16i1/v8i1, idx) returns an element of type i1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197384 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we have such types as legal vector types. The DAG combiner may generate some DAG nodes having such types but we don't have patterns to match them.
E.g. a load i32 and a bitcast i32 to v1i32 will be combined into a load v1i32:
bitcast (load i32) to v1i32 -> load v1i32.
So this patch fixes such problems for load/dup instructions.
If v1i8/v1i16/v1i32 are not legal any more, the code in this patch can be deleted. So I also add some FIXME.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197361 91177308-0d34-0410-b5e6-96231b3b80d8
