|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
getName() involves a hashtable lookup, so is expensive given how
frequently isIntrinsic() is called.  (In particular, many users cast to
IntrinsicInstr or one of its subclasses before calling
getIntrinsicID().)
This has an incidental functional change: Before, isIntrinsic() would
return true for any function whose name started with "llvm.", even if it
wasn't properly an intrinsic.  The new behavior seems more correct to
me, because it's strange to say that isIntrinsic() is true, but
getIntrinsicId() returns "not an intrinsic".
Some callers want the old behavior -- they want to know whether the
caller is a recognized intrinsic, or might be one in some other version
of LLVM.  For them, we added Function::hasLLVMReservedName(), which
checks whether the name starts with "llvm.".
This change is good for a 1.5% e2e speedup compiling a large Eigen
benchmark.
Reviewers: bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D22065
llvm-svn: 276942 | 
| | 
| 
| 
| 
| 
| 
| 
| | Factor out countDuplicatedInstructions to Count duplicated instructions at the
beginning and end of a diamond pattern. This is in prep for adding support for
diamonds that need to be tail-merged.
llvm-svn: 276910 | 
| | 
| 
| 
| 
| 
| | Add a const qualifier to ReverseBranchCondition.
llvm-svn: 276909 | 
| | 
| 
| 
| 
| 
| 
| 
| | compile time.
Differential Revision: https://reviews.llvm.org/D22839
llvm-svn: 276898 | 
| | 
| 
| 
| 
| 
| 
| | All allocas must be at least 1 byte at the MachineIR level so we allocate just
one byte.
llvm-svn: 276897 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | TargetOptions wants the ExceptionHandling enum. Move that to
MCTargetOptions.h to avoid transitively including Dwarf.h everywhere in
clang. Now you can add a DWARF tag without a full rebuild of clang
semantic analysis.
llvm-svn: 276883 | 
| | 
| 
| 
| 
| 
| 
| 
| | And implement it for AArch64, supporting x/w ADD/OR.
Differential Revision: https://reviews.llvm.org/D22373
llvm-svn: 276875 | 
| | 
| 
| 
| 
| 
| 
| 
| | registry"
This is causing a huge pile of buildbot failures.
llvm-svn: 276857 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.
This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.
Differential Revision: http://reviews.llvm.org/D21385
llvm-svn: 276856 | 
| | 
| 
| 
| 
| 
| 
| 
| | Using getZExtValue() will assert if the value doesn't fit into uint64_t - SHL was already doing this, I've just updated ASHR/LSHR to match
As mentioned on D22726
llvm-svn: 276855 | 
| | 
| 
| 
| 
| 
| | Differential Revision: https://reviews.llvm.org/D22669
llvm-svn: 276849 | 
| | 
| 
| 
| | llvm-svn: 276824 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Change the syntax to use `%0.sub8` to denote a subregister.
This seems like a more natural fit to denote subregisters; I also plan
to introduce a new ":classname" syntax in upcoming patches to denote the
register class of a vreg.
Note that this commit disallows plain identifiers to start with a '.'
character.  This shouldn't affect anything as external names/IR
references are all prefixed with '$'/'%', plain identifiers are only
used for instruction names, register mask names and subreg indexes.
Differential Revision: https://reviews.llvm.org/D22390
llvm-svn: 276815 | 
| | 
| 
| 
| 
| 
| 
| | Pretty straightforward, the only oddity is the MachineMemOperand (which it's
surprisingly difficult to share code for).
llvm-svn: 276799 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | In an instruction like:
	CFI_INSTRUCTION .cfi_def_cfa ...
we can drop the '.cfi_' prefix since that should be obvious by the
context:
	CFI_INSTRUCTION def_cfa ...
While being a terser and cleaner syntax this also prepares to dropping
support for identifiers starting with a dot character so we can use it
for expressions.
Differential Revision: http://reviews.llvm.org/D22388
llvm-svn: 276785 | 
| | 
| 
| 
| 
| 
| | Frame indices should use "addFrameIndex", not "addImm".
llvm-svn: 276775 | 
| | 
| 
| 
| 
| 
| | Tidies up the representation a bit in the common case.
llvm-svn: 276772 | 
| | 
| 
| 
| 
| 
| 
| 
| | Patch by Sunita Marathe
Differential Revision: http://reviews.llvm.org/D21920
llvm-svn: 276771 | 
| | 
| 
| 
| 
| 
| | NFC.
llvm-svn: 276763 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Instead of an ad-hoc collection of "buildInstr" functions with varying numbers
of registers, this uses variadic templates to provide for as many regs as
needed!
Also make IRtranslator use new "buildBr" function instead of some weird generic
one that no-one else would really use.
llvm-svn: 276762 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | If we move a last-use register read to a later position we may skip
intermediate segments. This may require us to not only extend the
segment before the NewIdx, but also extend the segment live-in to
OldIdx.
This switches LiveIntervalTest to use AMDGPU so we can test subregister
liveness.
llvm-svn: 276724 | 
| | 
| 
| 
| | llvm-svn: 276723 | 
| | 
| 
| 
| 
| 
| | Stack guard slot is live throughout the function.
llvm-svn: 276712 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This adds LLVM's 3 main cast instructions (inttoptr, ptrtoint, bitcast) to the
IRTranslator. The first two are direct translations (with 2 MachineInstr types
each). Since LLT discards information, a bitcast might become trivial and we
emit a COPY in those cases instead.
llvm-svn: 276690 | 
| | 
| 
| 
| | llvm-svn: 276677 | 
| | 
| 
| 
| | llvm-svn: 276676 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Some targets, notably AArch64 for ILP32, have different relocation encodings
based upon the ABI. This is an enabling change, so a future patch can use the
ABIName from MCTargetOptions to chose which relocations to use. Tested using
check-llvm.
The corresponding change to clang is in: http://reviews.llvm.org/D16538
Patch by: Joel Jones
Differential Revision: https://reviews.llvm.org/D16213
llvm-svn: 276654 | 
| | 
| 
| 
| | llvm-svn: 276597 | 
| | 
| 
| 
| | llvm-svn: 276481 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This adds the actual MachineLegalizeHelper to do the work and a trivial pass
wrapper that legalizes all instructions in a MachineFunction. Currently the
only transformation supported is splitting up a vector G_ADD into one acting on
smaller vectors.
llvm-svn: 276461 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This provides a better layering of responsibilities among different
aspects of PDB writing code.  Some of the MSF related code was
contained in CodeView, and some was in PDB prior to this.  Further,
we were often saying PDB when we meant MSF, and the two are
actually independent of each other since in theory you can have
other types of data besides PDB data in an MSF.  So, this patch
separates the MSF specific code into its own library, with no
dependencies on anything else, and DebugInfoCodeView and
DebugInfoPDB take dependencies on DebugInfoMsf.
llvm-svn: 276458 | 
| | 
| 
| 
| | llvm-svn: 276433 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | integer scalar/vector types
An extension of D19978, this patch replaces the default BITREVERSE evaluation of individual bit masks+shifts with block mask+shifts when we have integer elements of power-of-2 bits in size.
After calling BSWAP to reverse the order of the constituent bytes (which typically follows a similar approach), every neighbouring 4-bits, 2-bits and finally 1-bit pairs are masked off and swapped over with shifts.
In doing so we can significantly reduce the number of operations required.
Differential Revision: https://reviews.llvm.org/D21578
llvm-svn: 276432 | 
| | 
| 
| 
| | llvm-svn: 276410 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | When we failed to parse a function in the mir parser, we should abort
the whole compilation instead of continuing in a weird state. Indeed,
this was creating strange machine function passes failures that were
hard to understand, until we notice that the function actually did not
get parsed correctly!
llvm-svn: 276348 | 
| | 
| 
| 
| 
| 
| | This commit adds a generic SUB opcode to global-isel.
llvm-svn: 276308 | 
| | 
| 
| 
| 
| 
| | Group arithmetic operations, bitwise operations, and branch operations.
llvm-svn: 276305 | 
| | 
| 
| 
| 
| 
| | This commit adds a generic AND opcode to global-isel.
llvm-svn: 276297 | 
| | 
| 
| 
| 
| 
| 
| 
| | The clearance calculation did not take into account registers defined as outputs or clobbers in inline assembly machine instructions because these register defs are implicit.
Differential Revision: http://reviews.llvm.org/D22580
llvm-svn: 276266 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This patch fixes a very subtle bug in regmask calculation. Thanks to zan
jyu Wong <zyfwong@gmail.com> for bringing this to notice.
For example if CL is only clobbered than CH should not be marked
clobbered but CX, RCX and ECX should be mark clobbered. Previously for
each modified register all of its aliases are marked clobbered by
markRegClobbred() in RegUsageInfoCollector.cpp but that is wrong because
when CL is clobbered then MRI::isPhysRegModified() will return true for
CL, CX, ECX, RCX which is correct behavior but then for CX, EXC, RCX we
mark CH also clobbered as CH is aliased to CX,ECX,RCX so
markRegClobbred() is not required because isPhysRegModified already take
cares of proper aliasing register. A very simple test case has been
added to verify this change.
Please find relevant bug report here :
http://llvm.org/PR28567
Patch by Vivek Pandya <vivekvpandya@gmail.com>
Differential Revision: https://reviews.llvm.org/D22400
llvm-svn: 276235 | 
| | 
| 
| 
| 
| 
| 
| | This adds an (incomplete, inefficient) framework for deciding what to do with
some operation on a given type.
llvm-svn: 276184 | 
| | 
| 
| 
| 
| 
| 
| 
| | This should be all the low-level instruction selection needs to determine how
to implement an operation, with the remaining context taken from the opcode
(e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math).
llvm-svn: 276158 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Reverting this commit for now as it seems to be causing failures on
test-suite tests on the clang-ppc64le-linux-lnt bot.
This reverts commit r276044.
llvm-svn: 276068 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Add a check that the layout predecessor of a block is an actual CFG
predecssor of the block as well. No current code fails this check, but
upcoming patches can trigger this, and it makes sense to separate it
out.
llvm-svn: 276066 | 
| | 
| 
| 
| 
| 
| 
| 
| | canTailDuplicate accepts two blocks and returns true if the first can be
duplicated into the second successfully. Use this function to
encapsulate the heuristic.
llvm-svn: 276062 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This is a variant of scavengeRegister() that works for
enterBasicBlockEnd()/backward(). The benefit of the backward mode is
that it is not affected by incomplete kill flags.
This patch also changes
PrologEpilogInserter::doScavengeFrameVirtualRegs() to use the register
scavenger in backwards mode.
Differential Revision: http://reviews.llvm.org/D21885
llvm-svn: 276044 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This adds two pieces:
- RegisterScavenger:::enterBasicBlockEnd() which behaves similar to
  enterBasicBlock() but starts tracking at the end of the basic block.
- A RegisterScavenger::backward() method. It is subtly different
  from the existing unprocess() method which only considers uses with
  the kill flag set: If a value is dead at the end of a basic block with
  a last use inside the basic block, unprocess() will fail to mark it as
  live. However we cannot change/fix this behaviour because unprocess()
  needs to perform the exact reverse operation of forward().
Differential Revision: http://reviews.llvm.org/D21873
llvm-svn: 276043 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Also verify that we never try to set the size of a vreg associated
to a register class.
Report an error when we encounter that in MIR. Fix a testcase that
hit that error and had a size for no reason.
llvm-svn: 276012 | 
| | 
| 
| 
| | llvm-svn: 276011 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The following condition expression ( a >> n) & 1 is converted to "bt a, n" instruction. It works on all intel targets.
But on AVX-512 it was broken because the expression is modified to (truncate (a >>n) to i1).
I added the new sequence (truncate (a >>n) to i1) to the BT pattern.
Differential Revision: https://reviews.llvm.org/D22354
llvm-svn: 275950 |