Age | Commit message (Collapse) | Author |
|
Before this change, the writer would only emit FORWARDTYPEREF for some
operands, e.g. the first operand of BINOP but not the second, on the
grounds that the type of the second operand can be inferred. However,
that makes the format complicated.
Change the writer so that it always emits FORWARDTYPEREF for a forward
ref. This unifies PushValueAndType() and pushValue(). pushValue()
gains a call to EmitFnForwardTypeRef() so becomes the same as
PushValueAndType().
Change the reader to be stricter, so that it requires a FORWARDTYPEREF
to have been emitted in most cases. This is done by ignoring the
implied type argument.
Tasks still remaining:
* Make reader stricter so that multiple FORWARDTYPEREFs are disallowed.
* Remove now-unused Type arguments in the reader.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3507
TEST=new llvm-lit test + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17806003
|
|
For some reason, the size operand of "alloca" was represented using an
absolute value ID + type, unlike other instructions where relative
value IDs are used.
Change the "alloca" representation to be consistent with other
instructions, so that we can use PushValueAndType() in the writer and
getValue() in the reader.
Also take this opportunity to remove the field for alloca's result
type, since it's always i8* in PNaCl.
This is part of a cleanup to make forward reference handling stricter:
it removes a use of getOrCreateFnValueByID(), which isn't strict (that
is, it doesn't reject duplicate FORWARDTYPEREF records).
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3507
TEST=PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17757004
|
|
The magic number is no longer needed now that the reader for the old
switch representation has been removed (in
https://codereview.chromium.org/17764003), so we can remove this
baggage.
Also add a missing record size check to the reader.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3507
TEST=hello_world.pexe includes a switch statement; also PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17777005
|
|
The PNaCl pexe writer never writes this old representation.
This is part of a cleanup to make forward reference handling stricter:
it removes a use of getOrCreateFnValueByID(), which isn't strict (that
is, it doesn't reject duplicate FORWARDTYPEREF records).
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3507
TEST=PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17764003
|
|
* Don't preserve external linking for mem{cpy,move,cmp} during LTO.
* In the RewritePNaClLibraryCalls pass - add rewriting of mem* calls to
appropriate intrinsics, similarly to the way it was done for longjmp.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3493
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/17622003
|
|
PNaCl only supports a fixed data layout, so treat this as implicit in
the pexe file.
Add the data layout field back at read time, to prevent accidentally
using any architecture-specific backend data layout when translating,
and to ensure that any IR passes that use the data layout work
correctly.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3505
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17591014
|
|
The code is similar to the case for handling phi nodes.
It turns out that "select" on struct values can occur in practice with
use of C++ method pointers.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3514
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17706002
|
|
Revert this until we fix i1 sext. Currently, it uses LSL and ASR,
which are pseudo-instructions and get dropped on the floor when
generating .o files. We'll fix that, but for now revert to green
the bots.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3501
R=jfb@chromium.org
Review URL: https://codereview.chromium.org/17715002
|
|
The use of StripDeadPrototypes in PNaClABISimplify.cpp wasn't always
having an effect: it doesn't work if there are dead constant
references remaining to a function declaration. ReplacePtrsWithInts
was leaving some of these references behind, so fix it.
BUG=none
TEST=llvm-lit tests
Review URL: https://codereview.chromium.org/17636006
|
|
Disallow i1 on loads/stores and require the conversions to i8 to be
explicit. Add a pass, PromoteI1Ops, that adds the conversions.
(Load/store on i1 occur in practice in small_tests for some boolean
globals.)
Disallow i1 for most arithmetic/comparison operations since these
aren't very useful and it's a nuisance for a code generator to have to
support these. I haven't seen these occur in practice, but
PromoteI1Ops nevertheless expands them.
We still allow and/or/xor on i1 because these do occur in practice,
and they're less of a nuisance to handle because they never overflow:
no truncation to 1 bit is required, unlike with adds.
Restrict the type of alloca's argument. Clang always uses i32 here.
Disallow i1 in switch instructions. Clang doesn't generate i1
switches for booleans.
Move CopyLoadOrStoreAttrs() helper into a header to reuse.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3490
TEST=PNaCl toolchain trybots + GCC torture tests + Spec2k
Review URL: https://codereview.chromium.org/17356011
|
|
Do the same for memcpy/memmove/memset intrinsic calls that we have
already done for integer loads and stores: Remove assumptions about
pointer alignment by setting the alignment argument to 1. Make the
ABI checker require this.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3445
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17563008
|
|
Simplify the set of "alloca" instructions the ABI verifier allows.
Before this change, we used i8 arrays, such as:
alloca [8 x i8]
After this change, we will just use i8 with an explicit size value, so
that becomes:
alloca i8, i32 8
Allocation of variable-length arrays will require an explicit multiply
instruction. This means that the code generator no longer has to
handle an implicit multiplication in "alloca", reducing the burden on
fast-and-simple code generators a little. This means the PNaCl ABI
doesn't need to specify whether alloca's implicit multiplication
checks for overflow.
This doesn't affect what the backend generates. See
lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp, which handles
constant-size AllocaInsts (by filling out StaticAllocaMap) and which
is uses for both -O2 (SelectionDAG) and -O0 (FastISel) translation.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3343
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17631004
|
|
Disallow the other input types.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3378
R=jfb@chromium.org
Review URL: https://codereview.chromium.org/17613002
|
|
Simplify instruction records by adding concept of a forward type reference
map that maps ValueID's to types. Used to generate forward reference types
for instruction arguments that need a type because the forward reference
has not yet been generated.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3507
R=jvoung@chromium.org, mseaborn@chromium.org
Review URL: https://codereview.chromium.org/16963004
|
|
This change will fix the regression in -O0 translation time caused by
putting "align 1" on integer loads and stores, which was causing
FastISel to fall back to SelectionDAG more often.
> In X86FastISel::X86SelectStore(), improperly aligned stores are
> rejected and handled by the DAG-based ISel. However,
> X86FastISel::X86SelectLoad() makes no such requirement. There
> doesn't appear to be an x86 architectural correctness issue with
> allowing potentially unaligned store instructions. This patch
> removes this restriction.
>
> Patch by Jim Stichnot.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3445
TEST=PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17575003
|
|
Currently, the triple that gets put into pexes is
"armv7-none-linux-gnueabi". This is a wart that we don't want to
keep. We can remove the triple entirely; PNaCl doesn't need it.
We don't need to add a triple back at read time: (pnacl-)llc tells the
backend explicitly what target to use.
I'm leaving MODULE_CODE_TRIPLE defined in the enum for now because
pnacl-bcanalyzer still refers to it.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3505
TEST=PNaCl toolchain trybots + GCC torture tests + Spec2k
Review URL: https://codereview.chromium.org/17321009
|
|
Remove support for reading and writing the PARAMATTR_BLOCK_ID and
PARAMATTR_GROUP_BLOCK_ID blocks.
These blocks will no longer be written into pexes. While PNaCl
doesn't allow function attributes on normal functions,
Function::Create() always inserts them back on intrinsics, so
previously the PARAMATTR blocks were being written into pexes.
Remove paramattr fields from two record types:
* MODULE_CODE_FUNCTION records (function declarations). Also remove
the fields that follow paramattr, which PNaCl also does not use.
* FUNC_CODE_INST_CALL (function calls).
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3506
TEST=PNaCl toolchain trybots + GCC torture tests + Spec2k
Review URL: https://codereview.chromium.org/17419013
|
|
BUG=None
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/17519003
|
|
BUG=None
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/17115012
|
|
Change the ABI verifier to require "align 1" on non-atomic integer
accesses to prevent non-portable behaviour. Allow larger alignments
on floating point accesses as a concession to performance, because ARM
might not be able to do unaligned FP loads/stores efficiently.
Change StripAttributes to make pexes pass the ABI verifier.
Also update comments in StripAttributes to match some recent changes.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3445
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17094009
|
|
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3415
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17470005
|
|
Until there is an intrinsic to *set* the rounding mode,
this intrinsic to *get* the rounding mode isn't so useful.
Separately we will add a test that for each platform, the
initial rounding mode is "1" (round to nearest). That is
the case right now for x86, ARM, and MIPS.
(see https://codereview.chromium.org/16785003/)
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3491
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/17229007
|
|
Disallow large displacements in NaCl addressing modes, by
rejecting the fast-isel selection and using the logic in the
DAG-based isel.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3502
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/16959013
|
|
Creates a bitcode-local enumeration for calling conventions for the PNaCl bitcode file, so that the bitcode file is better protected from (accidental) changes in LLVM code.
Also removes invokes from the bitcode.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3497
R=dschuff@chromium.org, mseaborn@chromium.org
Review URL: https://codereview.chromium.org/17118002
|
|
Change pnacl-llc.cpp to enable the verifier. This causes two problems
which we fix:
* The ABI check for declared-but-not-defined functions fails in
streaming mode. Fixing this would involve changing the bitcode
reader. For now, disable this check when in streaming mode. Add a
flag to PNaClABIVerifyModule.
* ARM's GlobalMerge pass modifies functions' global variable
references to use ConstantExprs that the ABI checker rejects.
Address this by disabling GlobalMerge for now.
GlobalMerge does not provide much benefit at the moment anyway,
because, with the FlattenGlobals pass applied, GlobalMerge doesn't
merge variables with alignment >1.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3465
TEST=PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17190002
|
|
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3495
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16903003
|
|
"define available_externally void @foo()" would mean that the
definition of foo() can be dropped from the pexe, because a definition
of foo() can be found in an external native library. This is not
something we support for a PNaCl pexe.
Clang generates "available_externally" for non-static inline function
definitions at -O1, but not at -O0, and generally not at -O2 either
because inlining removes the "available_externally" definition.
"available_externally" gets removed at bitcode link time, so we can
disallow it in the ABI checker without any further work required.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3495
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17035015
|
|
This simplifies the ABI by reducing the number of linkage types we
have to check for and represent in the wire format.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3495
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/17084003
|
|
if the function calls _builtin_unwind_init()
Also fix the list of callee-saved registers returned by
X86RegisterInfo::getCalleeSavedRegisters
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3486
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/16987002
|
|
Do this stripping in the StripAttributes pass. Change the pass to be
a ModulePass so that it can modify global variables.
Change the ABI verifier to check this.
Also update a comment about "nuw" and "nsw".
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3415
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16991002
|
|
BUG=none
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/16838018
|
|
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3405
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/16836017
|
|
Fixes bug where we computed the length of fields buffer on the size of a pointer, rather then the actual length of the field.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3485
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/17003002
|
|
BUG=none
TEST=*.ll tests
Review URL: https://codereview.chromium.org/16865012
|
|
The backend currently treats llvm.expect as a nop
pass-through. Until it becomes more useful, we don't need
it in stable bitcode. It sounds like the backend may
prefer to use the !prof metadata instead.
The -lower-expect pass will convert it into branch
weights, which can be consumed by the middle end optimizer's
block placement pass.
It is already converted to !prof metadata when clang
is run with -O2, but not when clang is run at -O0.
Also move the llvm.frameaddress from the dev part of
the intrinsics test to the disallowed part of the test.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3378
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/16882002
|
|
Intrinsic::sin, Intrinsic::cos, etc., aren't generated.
Intrinsic::sqrt is implemented in hardware we support now.
If future hardware does not support it, we can supply
a library function in the runtime.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3339
TEST=scons, llvm test suite, gcc torture, spec2k
R=eliben@chromium.org
Review URL: https://codereview.chromium.org/16868002
|
|
Initially whitelisted to satisfy tests/toolchain/llvm_math_intrinsics.c,
which tests the intrinsics directly. Those tests now skip
ABI verification so they will continue to pass.
Outside of those direct uses, they are not used.
llvm.powi gets introduced during the llvm sandboxed build.
Clang CGBuiltin.cpp has a way to introduce Intrinsic::pow
and Intrinsic::powi. It does not introduce any of the other
intrinsics.
We can add them back later and supply something in compiler_rt
when clang or some transformation actually introduces them.
For now that is not the case.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3378
TEST= scons, llvm nightly, gcc torture, spec2k, naclports
R=eliben@chromium.org
Review URL: https://codereview.chromium.org/16794006
|
|
"nsw" and "nuw" -- "no signed wrap" and "no unsigned wrap" -- are not
used by the backend, which is not surprising because it makes no
difference to the hardware if arithmetic overflows.
Although "exact" is used by the backend to convert "sdiv exact" to an
"ashr" shift, it appears that "sdiv exact" does not get used in
practice, and arguably such a transformation belongs in the user
toolchain, not the PNaCl translator.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3483
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16746005
|
|
Rename countTrailingZeros to the older CountTrailingZeros_32, mark as localmod.
These patches fix correctness issues with ARM FastISel, and should make it faster while generating better code.
BUG= none
TEST= self
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/16712002
|
|
Previously, the pass could expand out struct_load+extractvalue
combinations (via ReplaceUsesOfStructWithFields()). This change makes
the pass more general by converting struct_loads to
scalar_load+insertvalue combinations and then by expanding out
insertvalue+extractvalue combinations.
This means the pass can now handle the insertvalue instructions that
are sometimes generated by the SROA pass. (Clang compiles ScummVM's
use of C++ method pointers to struct loads+stores which SROA generates
insertvalue instructions from.)
To make the pass more general, we also extend it to be able to handle
phi nodes of struct type. These are split into
extractvalue+scalar_phi+insertvalue combinations.
However, the pass is not yet fully general, because it doesn't handle:
* nested struct types
* array types
Change ExpandArithWithOverflow to rely on ExpandStructRegs'
insertvalue handling rather than the less general
ReplaceUsesOfStructWithFields() helper function, which can now be
removed.
SplitUpStore() no longer needs to handle Constants, because this case
is handled by ExpandExtractValue().
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3476
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16448006
|
|
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3469
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/16385002
|
|
Always use the standard C calling conventions. Disallow "fastcc" etc.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=2346
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16529004
|
|
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3405
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/15907008
|
|
Add a pass, StripAttributes, for doing this, and enable it.
Add an ABI check to reject these attributes.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=2346
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3415
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16325025
|
|
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3339
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16270007
|
|
Removing the unused declarations of setjmp()/longjmp() will be
necessary for future ABI checks which will reject these external
function declarations because they are not intrinsics.
StripDeadPrototypes is supposed to remove these declarations, but it
fails to do so because there are dead ConstantExprs referencing the
declarations. I suspect these are left behind by ReplacePtrsWithInts.
We could fix this by adding calls to removeDeadConstantUsers() to
StripDeadPrototypes or to ReplacePtrsWithInts, but for now it seems
cleaner to fix RewritePNaClLibraryCalls.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3429
TEST=*.ll tests + tested along with an ABI check
Review URL: https://codereview.chromium.org/15931009
|
|
It doesn't appear to be possible to set the address space on a
Function, but we can still put the check in checkGlobalValueCommon()
in case this changes in the future.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3343
TEST=*.ll tests
Review URL: https://codereview.chromium.org/15993019
|
|
Move most of the per-instruction checking in
PNaClABIVerifyFunctions::runOnFunction() to a top-level function so
that it can do an early exit to reject the instruction. Reporting
just a single error per instruction makes the test expectations easier
to understand and update.
Remove the check for metadata types. Metadata won't be part of
PNaCl's stable ABI, so if the metadata-rejecting check is disabled for
debugging purpose, we don't really need to recursively check the
metadata's types.
This lets us remove the recursive checks of Constants and types. We
now only accept a very restricted, non-recursive set of Constants
inside functions and global variable initialisers. This means
PNaClABITypeChecker doesn't need to be stateful any more, and its
methods can become static.
This change also fixes a hole where the operands of "switch"
instructions weren't fully checked.
Add a test to replace-ptrs-with-ints.ll to ensure that "undef" doesn't
appear directly in loads and stores.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3343
TEST=PNaCl toolchain trybots + GCC torture tests + LLVM test suite
Review URL: https://codereview.chromium.org/15780014
|
|
------------------------------------------------------------------------
r183035 | arnolds | 2013-05-31 12:53:50 -0700 (Fri, 31 May 2013) | 7 lines
LoopVectorize: PHIs with only outside users should prevent vectorization
We check that instructions in the loop don't have outside users (except if
they are reduction values). Unfortunately, we skipped this check for
if-convertable PHIs.
Fixes PR16184.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
------------------------------------------------------------------------
r183108 | vljn | 2013-06-03 08:44:42 -0700 (Mon, 03 Jun 2013) | 1 line
R600: CALL_FS consumes a stack size entry
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@183181 91177308-0d34-0410-b5e6-96231b3b80d8
|