| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Tablegen understands backslash as an escape char; that's sufficient.
Reviewers: jholewinski
Subscribers: llvm-commits, tra, jholewinski
Differential Revision: http://reviews.llvm.org/D17432
llvm-svn: 262372
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also simplify some of the embedded C++ logic.
No functional changes.
Reviewers: jholewinski
Subscribers: llvm-commits, tra, jholewinski
Differential Revision: http://reviews.llvm.org/D17354
llvm-svn: 262371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The _chkstk function is called by the compiler to probe the stack in an
order consistent with Windows' expectations. However, it is possible to
elide the call to _chkstk and manually adjust the stack pointer if we
can prove that the allocation is fixed size and smaller than the probe
size.
This shrinks chrome.dll, chrome_child.dll and chrome.exe by a
cummulative ~133 KB.
Differential Revision: http://reviews.llvm.org/D17679
llvm-svn: 262370
|
| |
|
|
|
|
|
| |
It is only ever used by obj2yaml and yaml2obj. No point in linking it
everywhere.
llvm-svn: 262368
|
| |
|
|
| |
llvm-svn: 262367
|
| |
|
|
|
|
|
| |
Code in visitEHPadPredecessors assume a little too much about the
validity of a cleanupret with an invalid cleanuppad operand.
llvm-svn: 262364
|
| |
|
|
| |
llvm-svn: 262363
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds the beginning of an update API to preserve MemorySSA. In particular,
this patch adds a way to remove memory SSA accesses when instructions are
deleted.
It also adds relevant unit testing infrastructure for MemorySSA's API.
(There is an actual user of this API, i will make that diff dependent on this one. In practice, a ton of opt passes remove memory instructions, so it's hopefully an obviously useful API :P)
Reviewers: hfinkel, reames, george.burgess.iv
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17157
llvm-svn: 262362
|
| |
|
|
|
|
|
|
|
| |
CIE augmentation data might contain non-printable characters.
The patch prints the data as a list of hex bytes.
Differential Revision: http://reviews.llvm.org/D17759
llvm-svn: 262361
|
| |
|
|
|
|
|
|
| |
This adds support to convert ProfileSummary object to Metadata and create a
ProfileSummary object from metadata. This would allow attaching profile summary
information to Module allowing optimization passes to use it.
llvm-svn: 262360
|
| |
|
|
|
|
|
| |
This reduces the number of bitcast nodes and generally cleans up the
DAG when bitcasting between integers and vectors everywhere.
llvm-svn: 262358
|
| |
|
|
| |
llvm-svn: 262357
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intrinsics
Summary:
This patch impleemnts DS_PERMUTE/DS_BPERMUTE instruction definitions and intrinsics,
which are new since VI.
Reviewers: tstellarAMD, arsenm
Subscribers: llvm-commits, arsenm
Differential Revision: http://reviews.llvm.org/D17614
llvm-svn: 262356
|
| |
|
|
| |
llvm-svn: 262354
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17713
llvm-svn: 262353
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the code below on 32-bit targets, x would previously get forwarded to g()
without sign-extension to 32 bits as required by the parameter attribute.
void g(signed short);
void f(unsigned short x) {
g(x);
}
llvm-svn: 262352
|
| |
|
|
| |
llvm-svn: 262351
|
| |
|
|
|
|
|
| |
Revert r262337 as "check-llvm ubsan" step failed on
sanitizer-x86_64-linux-fast buildbot.
llvm-svn: 262349
|
| |
|
|
| |
llvm-svn: 262347
|
| |
|
|
| |
llvm-svn: 262346
|
| |
|
|
| |
llvm-svn: 262344
|
| |
|
|
| |
llvm-svn: 262338
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes calculating correct value for builtin_object_size function
when pointer is used only in builtin_object_size function call and never
after that.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D17337
llvm-svn: 262337
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Idea behind this change is to make code shorter and as much common for all targets as possible. Let's even accept more code than is valid for a particular target, leaving it for the assembler to sort out.
64bit instructions decoding added.
Error\warning messages on unrecognized instructions operands added, InstPrinter allowed to print invalid operands helping to find invalid/unsupported code.
The change is massive and hard to compare with previous version, so it makes sense just to take a look on the new version. As a bonus, with a few TD changes following, it disassembles the majority of instructions. Currently it fully disassembles >300K binary source of some blas kernel.
Previous TODOs were saved whenever possible.
Patch by: Valery Pykhtin
Differential Revision: http://reviews.llvm.org/D17720
llvm-svn: 262332
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function lto_module_create_in_local_context() would previously
rely on the default LLVMContext being created for it by
LTOModule::makeLTOModule(). This context exits the program on
error and is not arranged to update sLastStringError in
tools/lto/lto.cpp.
Function lto_module_create_in_local_context() now creates an
LLVMContext by itself, sets it up correctly to its needs and then
passes it to LTOModule::createInLocalContext() which takes
ownership of the context and keeps it present for the lifetime of
the returned LTOModule.
Function LTOModule::makeLTOModule() is modified to take a
reference to LLVMContext (instead of a pointer) and no longer
creates a default context when nullptr is passed to it. Method
LTOModule::createInContext() that takes a pointer to LLVMContext
is removed because it allows to pass a nullptr to it. Instead
LTOModule::createFromBuffer() (that takes a reference to
LLVMContext) should be used.
Differential Revision: http://reviews.llvm.org/D17715
llvm-svn: 262330
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17692
llvm-svn: 262320
|
| |
|
|
|
|
|
|
|
|
| |
handler function.
This resolves https://llvm.org/bugs/show_bug.cgi?id=26412
Differential Revision: http://reviews.llvm.org/D17542
llvm-svn: 262319
|
| |
|
|
| |
llvm-svn: 262317
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch modifies the existing comparison, branch, conditional-move
and select patterns, and adds new ones where needed. Also, the updated
SLT{u,i,iu} set of instructions generate a GPR width result.
The majority of the code changes in the Mips back-end fix the wrong
assumption that the result of SETCC nodes always produce an i32 value.
The changes in the common code path account for the fact that in 64-bit
MIPS targets, i1 is promoted to i32 instead of i64.
Reviewers: dsanders
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D10970
llvm-svn: 262316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it is not present
Previosy, if actual instruction have one of optional operands then other optional operands listed before this also should be presented.
For example instruction v_fract_f32 v0, v1, mul:2 have one optional operand - OMod and do not have optional operand clamp. Previously this was not allowed because clamp is listed before omod in AsmString:
string AsmString = "v_fract_f32$vdst, $src0_modifiers$clamp$omod";
Making this work required some hacks (both OMod and Clamp match classes have same PredicateMethod).
Now, if MatchInstructionImpl meets formal optional operand that is not presented in actual instruction it skips this formal operand and tries to match current actual operand with next formal.
Patch by: Sam Kolton
Review: http://reviews.llvm.org/D17568
[AMDGPU] Assembler: Check immediate types for several optional operands in predicate methods
With this change you should place optional operands in order specified by asm string:
clamp -> omod
offset -> glc -> slc -> tfe
Fixes for several tests.
Depends on D17568
Patch by: Sam Kolton
Review: http://reviews.llvm.org/D17644
llvm-svn: 262314
|
| |
|
|
|
|
|
|
| |
Count .irp/.irpc in parseMacroLikeBody similar to .rept
Update tests.
Review: http://reviews.llvm.org/D17707
llvm-svn: 262313
|
| |
|
|
|
|
| |
earlier so we can stop masking in multiple places. NFC
llvm-svn: 262312
|
| |
|
|
| |
llvm-svn: 262310
|
| |
|
|
| |
llvm-svn: 262309
|
| |
|
|
|
|
| |
comments. NFC
llvm-svn: 262301
|
| |
|
|
|
|
|
| |
This fixes regressions exposed in existing AMDGPU tests in a
future commit when all loads are custom lowered.
llvm-svn: 262299
|
| |
|
|
|
|
|
|
| |
Technically you aren't supposed to emit these after type legalization
for some reason, and we use vector extracts of bitcasted integers
as the canonical way to do this.
llvm-svn: 262298
|
| |
|
|
| |
llvm-svn: 262297
|
| |
|
|
|
|
|
|
|
|
| |
This currently does not have the control over the bitwidth,
and there are missing optimizations to reduce the integer to
32-bit if it can be.
But in most situations we do want the sinking to occur.
llvm-svn: 262296
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CatchObjOffset is relative to the end of the EH registration node
for 32-bit x86 WinEH targets. A special sentinel value, 0, is used to
indicate that no catch object should be initialized.
This means that a catch object allocated immediately before the
registration node would be assigned a CatchObjOffset of 0, leading the
runtime to believe that a catch object should not be initialized.
To handle this, allocate the registration node prior to any other frame
object. This will ensure that catch objects will not be allocated
before the registration node.
This fixes PR26757.
Differential Revision: http://reviews.llvm.org/D17689
llvm-svn: 262294
|
| |
|
|
|
|
|
|
| |
Generally speaking, this can only happen with unreachable code.
However, neglecting to check for this condition would lead us to loop
forever.
llvm-svn: 262284
|
| |
|
|
| |
llvm-svn: 262279
|
| |
|
|
|
|
|
| |
Continuation of:
http://reviews.llvm.org/rL262269
llvm-svn: 262273
|
| |
|
|
| |
llvm-svn: 262270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intended effect of this patch in conjunction with:
http://reviews.llvm.org/rL259392
http://reviews.llvm.org/rL260145
is that customers using the AVX intrinsics in C will benefit from combines when
the load mask is constant:
__m128 mload_zeros(float *f) {
return _mm_maskload_ps(f, _mm_set1_epi32(0));
}
__m128 mload_fakeones(float *f) {
return _mm_maskload_ps(f, _mm_set1_epi32(1));
}
__m128 mload_ones(float *f) {
return _mm_maskload_ps(f, _mm_set1_epi32(0x80000000));
}
__m128 mload_oneset(float *f) {
return _mm_maskload_ps(f, _mm_set_epi32(0x80000000, 0, 0, 0));
}
...so none of the above will actually generate a masked load for optimized code.
This is the masked load counterpart to:
http://reviews.llvm.org/rL262064
llvm-svn: 262269
|
| |
|
|
|
|
|
| |
This change makes the verifier a little more paranoid. It was possible
to trick the verifier into crashing or infinite looping.
llvm-svn: 262268
|
| |
|
|
|
|
|
|
|
| |
We can actually have dependences between accesses with different
underlying types. Bail in this case.
A test will follow shortly.
llvm-svn: 262267
|
| |
|
|
|
|
|
|
| |
http://reviews.llvm.org/D9979
Patch by Richard Thomson (and some conflict resolution by me).
llvm-svn: 262266
|
| |
|
|
| |
llvm-svn: 262265
|
| |
|
|
| |
llvm-svn: 262262
|