Age | Commit message (Collapse) | Author |
|
libc++'s iostream values are extern, and never actually used in the headers (unlike libstdc++'s) which means that including iostream and doing something like (void)std::clog used to leave a global external ostream object declaration without a definition, which cause PNaCl's module ABI verifier to fail ('has no initializer' and 'is not a valid external symbol').
R=dschuff@chromium.org
BUG= http://code.google.com/p/nativeclient/issues/detail?id=3623
TEST= globalcleanup.ll
Review URL: https://codereview.chromium.org/33233002
|
|
setjmp()+longjmp()
There are two parts to this:
* PNaClSjLjEH.cpp expands out the "invoke", "landingpad" and "resume"
instructions, modifying the control flow to use setjmp().
* ExceptionInfoWriter.cpp lowers landingpads' clause lists to data
that PNaCl's C++ runtime library will interpret. This part will be
reused when we drop the SjLj part and create a stable ABI for
zero-cost EH.
This pass isn't enabled in PNaClABISimplify yet: I'll do that in a
separate change.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3696
TEST=*.ll tests (also tested end-to-end: plumbing for this will follow later)
Review URL: https://codereview.chromium.org/24777002
|
|
The pass gets confused in some cases when library functions get passed to
other functions as arguments, because use_iterator returns the call instruction.
The existing test (rewrite-longjmp-noncall-uses.ll) did not catch this problem
because there a bitcast constexpr was applied to the library function pointer,
and it came up as the use instead of the containing call.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3706
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/26952003
|
|
LowerNaClTargetArch has to return const PnaclTargetArchitectureMips_32 for
MIPS. The constant is later used in ResolvePNaClIntrinsics pass.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3602
R=jfb@chromium.org
Review URL: https://codereview.chromium.org/25887007
|
|
Its handling is the same as add (may overflow, may set upper bits)
R=jvoung@chromium.org, mseaborn@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3599
Review URL: https://codereview.chromium.org/24244008
|
|
Follow-up to https://codereview.chromium.org/22710004/
R=eliben@chromium.org
Review URL: https://codereview.chromium.org/23085007
|
|
16-bit atomics aren't handled properly by the current validator, this patch changes the translator so that on x86-32 it emulates 16-bit atomics with 32-bit atomics in a compare-exchange loop.
TEST= ./scons run_synchronization_sync_test bitcode=1 platform=x86-32
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3579
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2981
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/22760002
|
|
This should slightly reduce the size of generate pexes without compromising ABI stability since the code in DCE.cpp is so simple.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3613
TEST= tryjobs
R= kschimpf@chromium.org, eliben@chromium.org
Review URL: https://codereview.chromium.org/22710004
|
|
This is a follow-up to:
https://codereview.chromium.org/22240002/
And requires the Clang changes from:
https://codereview.chromium.org/22294002/
This new intrinsic represents ``asm("":::"~{memory}")`` as well as ``__sync_synchronize()``, and in IR it corresponds to a sequentially-consistent fence surrounded by ``call void asm sideeffect "", "~{memory}"()``.
R=jvoung@chromium.org
TEST= ninja check-all
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
Review URL: https://codereview.chromium.org/22474008
|
|
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/21898004
|
|
This is part of a bigger CL to fix C++11 in PNaCl, to commit in the following order:
- https://codereview.chromium.org/20552002
- https://codereview.chromium.org/20554002
- https://codereview.chromium.org/20560002
- https://codereview.chromium.org/20561002
This should be the last PNaCl ABI change for C11/C+11 atomic support.
Note that Clang already has a builtin for lock-free, but it's partly resolved by Clang's ExprConstant.cpp and CGBuiltin.cpp, whereas what we want is a call that becomes a constant at translation-time. I made the translation part fairly general so it's easy to support architectures where ``true`` isn't always the right answer.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
TEST= ./scons run_synchronization_cpp11_test --verbose bitcode=1 platform=x86-64
TEST= ninja check-all
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/20554002
|
|
This is often used as a compiler barrier and should "just work" in user code.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2345
R=eliben@chromium.org
TEST= (cd ./pnacl/build/llvm_x86_64 && ninja check-all)
Review URL: https://codereview.chromium.org/21178002
|
|
Following our discussion in the related bug, prefetch will not be part of our initial stable ABI.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3531
TEST= cd ./pnacl/build/llvm_x86_64; ninja check
R=jvoung@chromium.org
Review URL: https://codereview.chromium.org/19771015
|
|
|
|
first
|
|
|
|
Conflicts:
docs/LangRef.rst
include/llvm/CodeGen/CallingConvLower.h
include/llvm/IRReader/IRReader.h
include/llvm/Target/TargetMachine.h
lib/CodeGen/CallingConvLower.cpp
lib/IRReader/IRReader.cpp
lib/IRReader/LLVMBuild.txt
lib/IRReader/Makefile
lib/LLVMBuild.txt
lib/Makefile
lib/Support/MemoryBuffer.cpp
lib/Support/Unix/PathV2.inc
lib/Target/ARM/ARMBaseInstrInfo.cpp
lib/Target/ARM/ARMISelLowering.cpp
lib/Target/ARM/ARMInstrInfo.td
lib/Target/ARM/ARMSubtarget.cpp
lib/Target/ARM/ARMTargetMachine.cpp
lib/Target/Mips/CMakeLists.txt
lib/Target/Mips/MipsDelaySlotFiller.cpp
lib/Target/Mips/MipsISelLowering.cpp
lib/Target/Mips/MipsInstrInfo.td
lib/Target/Mips/MipsSubtarget.cpp
lib/Target/Mips/MipsSubtarget.h
lib/Target/X86/X86FastISel.cpp
lib/Target/X86/X86ISelDAGToDAG.cpp
lib/Target/X86/X86ISelLowering.cpp
lib/Target/X86/X86InstrControl.td
lib/Target/X86/X86InstrFormats.td
lib/Transforms/IPO/ExtractGV.cpp
lib/Transforms/InstCombine/InstCombineCompares.cpp
lib/Transforms/Utils/SimplifyLibCalls.cpp
test/CodeGen/X86/fast-isel-divrem.ll
test/MC/ARM/data-in-code.ll
tools/Makefile
tools/llvm-extract/llvm-extract.cpp
tools/llvm-link/CMakeLists.txt
tools/opt/CMakeLists.txt
tools/opt/LLVMBuild.txt
tools/opt/Makefile
tools/opt/opt.cpp
|
|
Add portable support for concurrency in PNaCl's ABI:
- Promote volatile to atomic.
- Promote all memory ordering to sequential consistency.
- Rewrite all atomic operations to frozen NaCl intrinsics for pexe.
- Rewrite atomic intrinsics to LLVM instructions for translation.
This change also adds documentation to the PNaCl language reference, as
well as tests where it makes sense.
A future CL could clean up more of our code which mentions atomics,
volatiles, memory orderings.
Multiple reviewers because this is a big patch:
- eliben: LLVM-fu and ResolvePNaClIntrinsics.
- dschuff: ABI stability.
- mseaborn: ABI stability.
- sehr: Tron-duty (fight for the user's programs to work).
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
R=dschuff@chromium.org, eliben@chromium.org, sehr@google.com
TEST= (cd ./pnacl/build/llvm_x86_64; ninja check-all) && ./pnacl/test.sh test-x86-32 && ./pnacl/test.sh test-x86-64 && ./pnacl/test.sh test-arm && ./pnacl/test.sh test-x86-32-sbtc && ./pnacl/test.sh test-x86-64-sbtc && ./pnacl/test.sh test-arm-sbtc
Review URL: https://codereview.chromium.org/17777004
|
|
GlobalOpt currently assumes only an external "main" is the "real main".
This is no longer the case for PNaCl, where we internalize "main". Make
the test more strict and PNaCl specific by checking that "main" is just
used once - in a call from "_start", but does not have to be external.
Note that this also addresses a possible bug in the optimization for C
code, since C does not guarantee that main is not recursive.
This CL's purpose is to address a SPEC performance regression - 10% in
183.equake. The regression appeared after our ABI change that made 'main'
internal, which disabled this particular optimization. The CL addresses
this by re-enabling the optimization and also being more C-standard
conforming.
BUG=None
Review URL: https://codereview.chromium.org/18615015
|
|
vectorizing loops with memory accesses to non-zero address spaces. It
simply dropped the AS info. Fixes PR16306.
Merged from r184103
Author: Pekka Jaaskelainen <pekka.jaaskelainen@tut.fi>
Date: Mon Jun 17 18:49:06 2013 +0000
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@185869 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Instead, defer the undefined behavior to runtime.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3537
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/18552007
|
|
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3532
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/18348008
|
|
Convert calls to this intrinsic to use the 32-bit variant instead. Do
the same for the memcpy and memmove intrinsics too.
Change the PNaCl ABI verifier to check this argument.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3530
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/18226003
|
|
* 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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3495
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16903003
|
|
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
|
|
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
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
|
|
"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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
------------------------------------------------------------------------
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
|
|
Makes the bitcode a tiny bit smaller, and avoids generating
shift left by 0 code under fast-isel.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3343
TEST=*.ll tests
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/15861029
|
|
The normal form introduced by ReplacePtrsWithInts (as documented in
the comments) is intended to have the property that ptrtoint and
inttoptr only convert to/from i32, not other size types.
Using IRBuilder's CreateZExtOrTrunc() broke that, though, because it
performs some constant folding on global variable references. Fix
this by creating CastInsts directly.
I found this via the ABI checks I've been writing, which gave this
error when building the sandboxed translator:
non-i32 ptrtoint: %expanded1 = ptrtoint void ()* @ARMCompilationCallback to i8
LLVM ERROR: PNaCl ABI verification failed
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3343
TEST=*.ll tests + tested full PNaCl build with ABI checks applied too
Review URL: https://codereview.chromium.org/15955012
|
|
Although PNaCl doesn't fully support struct types as varargs
arguments, there is a test in Spec2k (255.vortex) that passes a struct
as a varargs argument but never reads the argument using va_arg (which
is legal, but strange).
ExpandVarArgs was handling the struct argument by copying it with a
struct load+store. This is undesirable because currently SROA
converts that into code that uses extractvalue, which was rejected by
the PNaCl ABI checker. Struct load/store will soon be rejected by the
ABI checker too.
We could fix this by running ExpandStructRegs after ExpandVarArgs, but
it's cleaner for ExpandVarArgs to use memcpy() instead of struct
load+store. memcpy() is potentially more efficient because it avoids
having a temporary copy of the struct, and using memcpy() avoids
dependencies between IR passes.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3338
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3343
TEST=*.ll tests + built 255.vortex from Spec2k
Review URL: https://codereview.chromium.org/16232021
|
|
The constructor for getelementptr ConstantExprs does some constant
folding which can add 1 or 2 more indexes to the getelementptr. This
complicates checking for FlattenGlobals' normal form in the PNaCl ABI
checker.
Worse, the GCC torture tests turned up a pathological case where this
constant folding adds 4 indexes to the getelementptr and leaves the
original struct type behind:
@q = global i8* getelementptr inbounds (
%union.u* bitcast ([260 x i8]* @v to %union.u*),
i32 0, i32 0, i32 0, i32 0, i32 4)
That comes from the following code in
gcc/testsuite/gcc.c-torture/execute/pr43784.c:
struct s {
unsigned char a[256];
};
union u {
struct { struct s b; int c; } d;
struct { int c; struct s b; } e;
};
static union u v;
static struct s *q = &v.e.b;
We can fix this by using ptrtoint+add instead of
getelementptr+bitcast, because ConstantExpr won't automatically
convert ptrtoint to something else.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3113
TEST=*.ll tests + PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/15647009
|
|
These markers work in a similar way to llvm.lifetime.start/end, so we
should remove them for similar reasons: it's not very well defined how
one marker cancels out the effects of the other.
Arguably, invariant.start/end are less useful than lifetime.start/end.
They are ignored by the backend. They are generated in fewer places:
invariant.start is generated by Clang (at -O1 or higher) when a const
global is initialised with a non-POD initialiser. invariant.end is
apparently not generated at all.
Do the stripping in ReplacePtrsWithInts for consistency with the
existing lifetime.start/end stripping.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3443
TEST=PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/15995004
|
|
Run StripDeadPrototypes as a final pass to ensure that the prototypes
for lifetime.start/end are removed.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3443
TEST=PNaCl toolchain trybots
Review URL: https://codereview.chromium.org/16063005
|
|
Clang's implementation of C++ method pointers generates IR that uses
LLVM registers with struct type -- specifically, loads and stores of
struct values, and extractvalue instructions. See
lib/CodeGen/ItaniumCXXABI.cpp in Clang. Add a pass, ExpandStructRegs,
which expands out those uses.
Factor out a function from ExpandArithWithOverflow so that the two
passes can share some code.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3343
TEST=*.ll tests + trybots + GCC torture tests
Review URL: https://codereview.chromium.org/15692014
|