| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
calculate builtin_object_size if argument is a removable pointer
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
Reland the original change with a small modification (first do a null check
and then do the cast) to satisfy ubsan.
llvm-svn: 263011
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Supprot DPP syntax as used in SP3 (except several operands syntax).
Added dpp-specific operands in td-files.
Added DPP flag to TSFlags to determine if instruction is dpp in InstPrinter.
Support for VOP2 DPP instructions in td-files.
Some tests for DPP instructions.
ToDo:
- VOP2bInst:
- vcc is considered as operand
- AsmMatcher doesn't apply mnemonic aliases when parsing operands
- v_mac_f32
- v_nop
- disable instructions with 64-bit operands
- change dpp_ctrl assembler representation to conform sp3
Review: http://reviews.llvm.org/D17804
llvm-svn: 263008
|
| |
|
|
|
|
|
|
|
| |
Support legacy SP3 abs(v1) syntax. InstPrinter still uses |v1|.
Add tests.
Differential Revision: http://reviews.llvm.org/D17887
llvm-svn: 263006
|
| |
|
|
|
|
|
|
| |
s_setpc_b64 has just one 64-bit source which is the address of instruction to jump to.
Differential Revision: http://reviews.llvm.org/D17888
llvm-svn: 263005
|
| |
|
|
| |
llvm-svn: 262998
|
| |
|
|
| |
llvm-svn: 262995
|
| |
|
|
| |
llvm-svn: 262989
|
| |
|
|
| |
llvm-svn: 262988
|
| |
|
|
|
|
|
|
| |
This implements a very simple conservative transformation that doesn't
require more than linear code size growth. There's room for much more
optimization in this space.
llvm-svn: 262982
|
| |
|
|
|
|
|
|
|
| |
Building on the previous change, this generalizes
ScalarEvolution::getRangeViaFactoring to work with
{Ext(C?A:B)+k0,+,Ext(C?A:B)+k1} where Ext can be a zero extend, sign
extend or truncate operation, and k0 and k1 are constants.
llvm-svn: 262979
|
| |
|
|
|
|
|
|
| |
This change generalizes ScalarEvolution::getRangeViaFactoring to work
with {Ext(C?A:B),+,Ext(C?A:B)} where Ext can be a zero extend, sign
extend or truncate operation.
llvm-svn: 262978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to provide a parallel (threaded) ThinLTO scheme
for linker plugin use through the libLTO C API.
The intent of this patch is to provide a first implementation as a
proof-of-concept and allows linker to start supporting ThinLTO by
definiing the libLTO C API. Some part of the libLTO API are left
unimplemented yet. Following patches will add support for these.
The current implementation can link all clang/llvm binaries.
Differential Revision: http://reviews.llvm.org/D17066
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262977
|
| |
|
|
|
|
|
| |
reference (NFC)
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262976
|
| |
|
|
| |
llvm-svn: 262956
|
| |
|
|
| |
llvm-svn: 262953
|
| |
|
|
| |
llvm-svn: 262952
|
| |
|
|
|
|
|
|
| |
The fix consisting in using the library call for atomic compare and swap when
the instruction is not safe to use may be incorrect. Indeed the library call may
not exist on all platform. In other words, we need a better fix!
llvm-svn: 262943
|
| |
|
|
|
|
|
| |
Test to be committed in follow up commit, per discussion in D17097.
http://reviews.llvm.org/D17097
llvm-svn: 262942
|
| |
|
|
| |
llvm-svn: 262940
|
| |
|
|
|
|
|
| |
This was inadvertently omitted from r262774, which added the mutation
interface.
llvm-svn: 262939
|
| |
|
|
| |
llvm-svn: 262937
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, grosbach, resistor
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D17636
llvm-svn: 262936
|
| |
|
|
|
|
|
|
| |
ZERO_EXTEND_VECTOR_INREG"
This caused PR26870.
llvm-svn: 262935
|
| |
|
|
| |
llvm-svn: 262930
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17953
llvm-svn: 262929
|
| |
|
|
|
|
| |
This reverts commit r262670 due to compile failure.
llvm-svn: 262916
|
| |
|
|
| |
llvm-svn: 262907
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and scalar
We follow the comments mentioned in http://reviews.llvm.org/D16842#344378 to
implement this new patch.
This patch implements the following vsx instructions:
Vector load/store:
lxv lxvx lxvb16x lxvl lxvll lxvh8x lxvwsx
stxv stxvb16x stxvh8x stxvl stxvll stxvx
Scalar load/store:
lxsd lxssp lxsibzx lxsihzx
stxsd stxssp stxsibx stxsihx
21 instructions
Phabricator: http://reviews.llvm.org/D16919
llvm-svn: 262906
|
| |
|
|
|
|
|
| |
Also note that the operand order changed; the default label is now listed
after the regular labels.
llvm-svn: 262903
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-applies r262886 with a fix for 32 bit platforms that have 8 byte
pointer alignment, effectively reverting r262892.
Original Message:
Currently some SDNode operands are malloc'd, some are stored inline in
subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
This scheme is complex, inconsistent, and makes refactoring SDNodes
fairly difficult.
Instead, we can allocate all of the operands using an ArrayRecycler
that wraps a BumpPtrAllocator. This keeps the cache locality when
iterating operands, improves locality when iterating SDNodes without
looking at operands, and vastly simplifies the ownership semantics.
It also means we stop overallocating SDNodes by 2-3x and will make it
simpler to fix the rampant undefined behaviour we have in how we
mutate SDNodes from one kind to another (See llvm.org/pr26808).
This is NFC other than the changes in memory behaviour, and I ran some
LNT tests to make sure this didn't hurt compile time. Not many tests
changed: there were a couple of 1-2% regressions reported, but there
were more improvements (of up to 4%) than regressions.
llvm-svn: 262902
|
| |
|
|
|
|
|
|
| |
parser.
Thanks to Ahmed Bougacha for noticing!
llvm-svn: 262899
|
| |
|
|
| |
llvm-svn: 262897
|
| |
|
|
| |
llvm-svn: 262896
|
| |
|
|
|
|
| |
register class.
llvm-svn: 262893
|
| |
|
|
|
|
|
|
|
| |
Looks like the largest SDNode is different between 32 and 64 bit now,
so this is breaking 32 bit bots. Reverting while I figure out a fix.
This reverts r262886.
llvm-svn: 262892
|
| |
|
|
| |
llvm-svn: 262891
|
| |
|
|
|
|
|
|
| |
instructions.
By complex types, I mean aggregate or vector types.
llvm-svn: 262890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently some SDNode operands are malloc'd, some are stored inline in
subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
This scheme is complex, inconsistent, and makes refactoring SDNodes
fairly difficult.
Instead, we can allocate all of the operands using an ArrayRecycler
that wraps a BumpPtrAllocator. This keeps the cache locality when
iterating operands, improves locality when iterating SDNodes without
looking at operands, and vastly simplifies the ownership semantics.
It also means we stop overallocating SDNodes by 2-3x and will make it
simpler to fix the rampant undefined behaviour we have in how we
mutate SDNodes from one kind to another (See llvm.org/pr26808).
This is NFC other than the changes in memory behaviour, and I ran some
LNT tests to make sure this didn't hurt compile time. Not many tests
changed: there were a couple of 1-2% regressions reported, but there
were more improvements (of up to 4%) than regressions.
llvm-svn: 262886
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
Before this change, we would get the type definition in the middle
of the instruction.
E.g., %0(48) = G_ADD %struct_alias = type { i32, i16 } %edi, %edi
Now, we have just the expected type name:
%0(48) = G_ADD %struct_alias %edi, %edi
llvm-svn: 262885
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Without actually parsing a type it is difficult to perdict where
the type definition ends. In other words, instead of expecting
the user of the parser API to hand over only the relevant bits
of the string being parsed, take the whole string, parse the type,
and get back the number of characters that have been read.
This will be used by the MIR testing infrastructure.
llvm-svn: 262884
|
| |
|
|
| |
llvm-svn: 262883
|
| |
|
|
| |
llvm-svn: 262880
|
| |
|
|
| |
llvm-svn: 262879
|
| |
|
|
|
|
|
|
|
|
| |
TSan instrumentation functions for atomic stores, loads, and cmpxchg work on
integer value types. This patch adds casts before calling TSan instrumentation
functions in cases where the value is a pointer.
Differential Revision: http://reviews.llvm.org/D17833
llvm-svn: 262876
|
| |
|
|
|
|
|
|
| |
Now the type API is always available, but when global-isel is not
built the implementation does nothing.
Note: The implementation free of ifdefs is WIP and tracked here in PR26576.
llvm-svn: 262873
|
| |
|
|
|
|
|
| |
The mir infrastructure will need this for generic instructions and currently
this feature was only available through the anonymous TypePrinter class.
llvm-svn: 262869
|
| |
|
|
|
|
|
| |
This is useful for MIR serialization. Indeed generic machine instructions
must have a type and we don't want to duplicate the logic in the MIParser.
llvm-svn: 262868
|
| |
|
|
| |
llvm-svn: 262867
|
| |
|
|
| |
llvm-svn: 262864
|
| |
|
|
| |
llvm-svn: 262862
|