| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
This code is based on the existing LLVM Go bindings project hosted at:
https://github.com/go-llvm/llvm
Note that all contributors to the gollvm project have agreed to relicense
their changes under the LLVM license and submit them to the LLVM project.
Differential Revision: http://reviews.llvm.org/D5684
llvm-svn: 219976
|
| |
|
|
|
|
| |
These days -std-compile-opts was just a silly alias for -O3.
llvm-svn: 219951
|
| |
|
|
|
|
|
| |
Added avx512_binop_rm_vl multiclass for VL subset
Added encoding tests
llvm-svn: 219390
|
| |
|
|
|
|
| |
This is necessary for masking vextract*x4.
llvm-svn: 219359
|
| |
|
|
|
|
|
|
|
|
| |
Interchangeable commit ids can now be used on this git-svnrevert, which
will figure out what kind of commit that is (if you use format rNNNN for SVN
commits) and make sure the right ids are used in the right places.
It's a little bit more robust and user-friendly.
llvm-svn: 219290
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
FastISel has a fixed set of virtual functions that are overridden by the
tablegen-generated code for each target. These functions are distinguished by
the kinds of operands, e.g., register + immediate = "ri". The FastISel emitter
has been blindly emitting functions with different combinations of operand
kinds, even for combinations that are completely unused by FastISel, e.g.,
"fastEmit_rrr". Change to filter out functions that will be irrelevant for
FastISel and do not bother generating the code for them. Also add explicit
"override" keywords for the virtual functions that are overridden.
llvm-svn: 218838
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
No functionality change intended.
This implements Elena's idea to put the new additionalOperand outside the
switch to cover all cases
(http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140929/237763.html).
Note only nontrivial change is in MRMSrcMemFrm. This requires an inclusive
interval of [2, 4] because we have prefix-dependent *optional* immediate
operand.
llvm-svn: 218790
|
| |
|
|
|
|
| |
Added new operand type for intrinsics (IIT_V64)
llvm-svn: 218668
|
| |
|
|
| |
llvm-svn: 218563
|
| |
|
|
|
|
|
|
|
| |
This fixes bit assignments like this
Inst{7-0} = Foo{9-2}
Patch by Steve King.
llvm-svn: 218560
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handle struct's correctly on big-endian N32/N64 return values.
Summary:
The N32/N64 ABI's require that structs passed in registers are laid out
such that spilling the register with 'sd' places the struct at the lowest
address. For little endian this is trivial but for big-endian it requires
that structs are shifted into the upper bits of the register.
We also require that structs passed in registers have the 'inreg'
attribute for big-endian N32/N64 to work correctly. This is because the
tablegen-erated calling convention implementation only has access to the
lowered form of struct arguments (one or more integers of up to 64-bits
each) and is unable to determine the original type.
Reviewers: vmedic
Reviewed By: vmedic
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5286
llvm-svn: 218451
|
| |
|
|
| |
llvm-svn: 218369
|
| |
|
|
| |
llvm-svn: 218368
|
| |
|
|
| |
llvm-svn: 218307
|
| |
|
|
|
|
|
|
|
|
| |
As far as I can tell UTF-8 has been supported since the beginning of Python's
codec support, and it's the de facto standard for text these days, at least
for primarily-English text. This allows us to put Unicode into lit RUN lines.
rdar://problem/18311663
llvm-svn: 217688
|
| |
|
|
| |
llvm-svn: 217567
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parsing (and latent bug in the instruction definitions).
This is effectively a revert of r136287 which tried to address
a specific and narrow case of immediate operands failing to be accepted
by x86 instructions with a pretty heavy hammer: it introduced a new kind
of operand that behaved differently. All of that is removed with this
commit, but the test cases are both preserved and enhanced.
The core problem that r136287 and this commit are trying to handle is
that gas accepts both of the following instructions:
insertps $192, %xmm0, %xmm1
insertps $-64, %xmm0, %xmm1
These will encode to the same byte sequence, with the immediate
occupying an 8-bit entry. The first form was fixed by r136287 but that
broke the prior handling of the second form! =[ Ironically, we would
still emit the second form in some cases and then be unable to
re-assemble the output.
The reason why the first instruction failed to be handled is because
prior to r136287 the operands ere marked 'i32i8imm' which forces them to
be sign-extenable. Clearly, that won't work for 192 in a single byte.
However, making thim zero-extended or "unsigned" doesn't really address
the core issue either because it breaks negative immediates. The correct
fix is to make these operands 'i8imm' reflecting that they can be either
signed or unsigned but must be 8-bit immediates. This patch backs out
r136287 and then changes those places as well as some others to use
'i8imm' rather than one of the extended variants.
Naturally, this broke something else. The custom DAG nodes had to be
updated to have a much more accurate type constraint of an i8 node, and
a bunch of Pat immediates needed to be specified as i8 values.
The fallout didn't end there though. We also then ceased to be able to
match the instruction-specific intrinsics to the instructions so
modified. Digging, this is because they too used i32 rather than i8 in
their signature. So I've also switched those intrinsics to i8 arguments
in line with the instructions.
In order to make the intrinsic adjustments of course, I also had to add
auto upgrading for the intrinsics.
I suspect that the intrinsic argument types may have led everything down
this rabbit hole. Pretty happy with the result.
llvm-svn: 217310
|
| |
|
|
| |
llvm-svn: 217123
|
| |
|
|
|
|
|
|
|
|
| |
This is the final round of renaming. This changes tblgen to emit lower-case
function names for FastEmitInst_* and FastEmit_*, and updates all its uses
in the source code.
Reviewed by Eric
llvm-svn: 217075
|
| |
|
|
| |
llvm-svn: 217023
|
| |
|
|
|
|
| |
Just using insert of a pair this time instead of emplace.
llvm-svn: 217018
|
| |
|
|
|
|
| |
std::map::emplace isn't working on some of the bots.
llvm-svn: 217015
|
| |
|
|
| |
llvm-svn: 217014
|
| |
|
|
|
|
| |
FixedLenDecoderEmitter. Also remove unused copy constructor of FilterChooser.
llvm-svn: 217013
|
| |
|
|
|
|
| |
so don't emit the unused itinerary variables
llvm-svn: 216993
|
| |
|
|
|
|
|
|
| |
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reinstates commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 216982
|
| |
|
|
|
|
|
|
| |
This removes static initializers from the backends which generate this data, and also makes this struct match the other Tablegen generated structs in behaviour
Reviewed by Andy Trick and Chandler C
llvm-svn: 216919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Just fixing comments, no functional change.
Test Plan: N/A
Reviewers: jfb
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D5130
llvm-svn: 216784
|
| |
|
|
| |
llvm-svn: 216583
|
| |
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216525
|
| |
|
|
|
|
| |
'const' from some other ArrayRef uses since its implicitly const already.
llvm-svn: 216524
|
| |
|
|
| |
llvm-svn: 216442
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Extended avx512_icmp_packed multiclass by masking versions.
Added avx512_icmp_packed_rmb multiclass for embedded broadcast versions.
Added corresponding _vl multiclasses.
Added encoding tests for CPCMP{EQ|GT}* instructions.
Add more fields for X86VectorVTInfo.
Added AVX512VLVectorVTInfo that include X86VectorVTInfo for 512/256/128-bit versions
Differential Revision: http://reviews.llvm.org/D5024
llvm-svn: 216383
|
| |
|
|
| |
llvm-svn: 216351
|
| |
|
|
| |
llvm-svn: 216350
|
| |
|
|
| |
llvm-svn: 216348
|
| |
|
|
|
|
| |
std::unique_ptr
llvm-svn: 216223
|
| |
|
|
|
|
| |
needing to mention the size.
llvm-svn: 216158
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new property: isInsertSubreg and the related target hooks:
TargetIntrInfo::getInsertSubregInputs and
TargetInstrInfo::getInsertSubregLikeInputs to specify that a target specific
instruction is a (kind of) INSERT_SUBREG.
The approach is similar to r215394.
<rdar://problem/12702965>
llvm-svn: 216139
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new property: isExtractSubreg and the related target hooks:
TargetIntrInfo::getExtractSubregInputs and
TargetInstrInfo::getExtractSubregLikeInputs to specify that a target specific
instruction is a (kind of) EXTRACT_SUBREG.
The approach is similar to r215394.
<rdar://problem/12702965>
llvm-svn: 216130
|
| |
|
|
| |
llvm-svn: 216048
|
| |
|
|
| |
llvm-svn: 216047
|
| |
|
|
|
|
|
|
|
|
| |
Implement `uselistorder` and `uselistorder_bb` assembly directives,
which allow the use-list order to be recovered when round-tripping to
assembly.
This is the bulk of PR20515.
llvm-svn: 216025
|
| |
|
|
|
|
|
|
|
|
| |
ARM in particular is getting dangerously close to exceeding 32 bits worth of
possible subtarget features. When this happens, various parts of MC start to
fail inexplicably as masks get truncated to "unsigned".
Mostly just refactoring at present, and there's probably no way to test.
llvm-svn: 215887
|
| |
|
|
|
|
|
|
| |
avoid needing to mention the size."
Getting a weird buildbot failure that I need to investigate.
llvm-svn: 215870
|
| |
|
|
|
|
| |
needing to mention the size.
llvm-svn: 215868
|
| |
|
|
|
|
|
| |
I'm using this to try to find more minimal test cases by re-fuzzing
within a specific domain once errors are found.
llvm-svn: 215823
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch changes the way xfail and unsupported tests are displayed.
This output is only displayed when the --show-unsupported/--show-xfail flags are passed to lit.
Currently xfail/unsupported tests are printed during the run of the test-suite. I think its better to display this information during the summary instead.
This patch removes the printing of these tests from when they are run to the summary.
Reviewers: ddunbar, EricWF
Reviewed By: EricWF
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D4842
llvm-svn: 215809
|
| |
|
|
|
|
|
|
|
|
| |
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)
Changes made by clang-tidy with minor tweaks.
llvm-svn: 215558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Especially with blends and large tree heights there was a problem with
the fuzzer where it would end up with enough undef shuffle elements in
enough parts of the tree that in a birthday-attack kind of way we ended
up regularly having large numbers of undef elements in the result. I was
seeing reasonably frequent cases of *all* results being undef which
prevents us from doing any correctness checking at all. While having
undef lanes is important, this was too much.
So I've tried to apply some math to the probabilities of having an undef
lane and balance them against the tree height. Please be gentle, I'm
really terrible at math. I probably made a bunch of amateur mistakes
here. Fixes, etc. are quite welcome. =D At least in running it some, it
seems to be producing more interesting (for correctness testing)
results.
llvm-svn: 215540
|