Age | Commit message (Collapse) | Author |
|
BUG=3178
Review URL: https://codereview.chromium.org/12088028
|
|
Apparently OSX's bash doesn't support it.
R=eliben@chromium.org,jvoung@chromium.org
BUG=none
TEST=llvm regression
Review URL: https://codereview.chromium.org/12089002
|
|
The old option recommendation is deprecated.
R=jvoung@chromium.org
BUG=
Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-llvm.git;a=commit;h=64dafdc
Review URL: https://codereview.chromium.org/12079003
|
|
Loosely based on lib/VMCore/TypeFinder.cpp but I can't use that directly because it's not streaming-friendly.
constexprs in initializers are also supported.
R=jvoung@chromium.org,eliben@chromium.org,mseaborn@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2196
TEST=llvm regression
Review URL: https://codereview.chromium.org/12038079
|
|
Register t8 is reserved for thread pointer, and it can not be changed.
Thus, the value it has can be trusted, it points to the safe data zone
and there is no need to guard it.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2275
TEST= run smoke tests
Review URL: https://codereview.chromium.org/11883035
|
|
(the current tests only cover allowed opcodes; no testing yet of types, attributes, etc).
R=jvoung@chromium.org,eliben@chromium.org,mseaborn@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2196
TEST= LLVM regression
Review URL: https://codereview.chromium.org/11896044
|
|
This fixes the move of the verifier passes from lib/Transforms to
lib/Analysis, and adds tests of the current verifier checks.
No new functionality.
R=jvoung@chromium.org,eliben@chromium.org,mseaborn@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2196
Review URL: https://codereview.chromium.org/12017019
|
|
They were added a while back to debug the use of self-deleting temp files.
Remove now, otherwise buildbot logs will show this spew.
BUG=none
Review URL: https://codereview.chromium.org/11981003
|
|
This is the skeleton for a verifier for the portion of the PNaCl bitcode ABI
that can be verified after the bitcode has been read into a Module object.
There is a ModulePass for module-level rules (e.g. GV linkage types) and a
FunctionPass for rules that apply to function bodies (e.g. legal instructions).
They are separated this way to keep the verifier streaming-friendly.
For now, the passes are registered but not hooked up, so they can only be run
manually via opt.
There are 2 bits of actual functionality, just so each pass has something to do:
The ModulePass checks the linkage types of GVs, and the FunctionPass checks
instruction opcodes. For now only the terminator instructions are checked, but
the idea is to add the rest of the allowed instructions to the whitelist,
and possibly call operand checks from the switch statement as well.
For now we just print messagees to stderr, but we will probably want a better
way to plumb the errors in the browser in the future.
R=jvoung@chromium.org,sehr@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2196
Review URL: https://codereview.chromium.org/11986002
|
|
Previously if compilation was slower than download, bitcode waiting to be
compiled would accumulate in the SRPCStreamer buffer in llc. This CL limits
the size of that buffer and instead causes the RPC called from the browser
to block until there is room (i.e., the compilation has consumed enough
to cach up). This reduces the memory requirements on the untrusted side, and
also makes it possible for the browser plugin to get an estimate of the
progress of the compilation
R=jvoung@chromium.org,robertm@chromium.org
BUG=none
Review URL: https://codereview.chromium.org/11360087
|
|
It keeps the same Module interface as the existing/old deplibs feature, but populates the library list from the metadata after reading the bitcode/LL into the Module.
Keeping the same module interface will allow us to keep the existing uses (e.g. in the gold plugin) as they are.
Internally it still uses the LibraryList variable, but uses it basically as a cache backed by the metadata.
BUG=
Review URL: https://codereview.chromium.org/11615013
|
|
deplib features commented out due to removal upstream;
will add back as a localmod
Conflicts:
include/llvm/ADT/Triple.h
include/llvm/MC/MCAssembler.h
include/llvm/Target/TargetFrameLowering.h
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
lib/CodeGen/AsmPrinter/DwarfDebug.h
lib/CodeGen/BranchFolding.cpp
lib/LLVMBuild.txt
lib/Linker/LinkArchives.cpp
lib/MC/MCAssembler.cpp
lib/MC/MCELFStreamer.cpp
lib/Makefile
lib/Target/ARM/ARMExpandPseudoInsts.cpp
lib/Target/ARM/ARMFrameLowering.cpp
lib/Target/ARM/ARMISelLowering.cpp
lib/Target/ARM/ARMSubtarget.h
lib/Target/ARM/ARMTargetObjectFile.cpp
lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp
lib/Target/Mips/MipsInstrFPU.td
lib/Target/Mips/MipsInstrInfo.td
lib/Target/X86/X86CodeEmitter.cpp
lib/Target/X86/X86Subtarget.h
lib/VMCore/Module.cpp
test/MC/MachO/ARM/nop-armv4-padding.s
tools/Makefile
tools/llc/llc.cpp
tools/lto/LTOModule.cpp
tools/lto/lto.cpp
|
|
Implementation of llvm.nacl.read.tp and support for nacl-expand-tls for MIPS.
Also, calculation of thread pointer is now aware of TLSUseCall flag.
Small fix (make T6, T7 and T8 unavailable as argument registers) for FastCC
added too.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2275
TEST= build nexe for MIPS32 target with nacl-expand-tls option.
Review URL: https://codereview.chromium.org/11695002
|
|
incorrect -sfi-<xx> flags
BUG=none
Review URL: https://codereview.chromium.org/11759018
|
|
I'll update pnacl/scripts/lit_known_failures.txt at the same time as I update the DEPS.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3168 https://code.google.com/p/nativeclient/issues/detail?id=1711
R= eliben@chromium.org
TESTS= ./pnacl/build/llvm_x86_64/Release+Asserts/bin/llvm-mc -mcpu=cortex-a8 -triple arm-unknown-unknown -show-encoding ./pnacl/git/llvm/test/MC/ARM/arm_instructions.s | ./pnacl/build/llvm_x86_64/Release+Asserts/bin/FileCheck ./pnacl/git/llvm/test/MC/ARM/arm_instructions.s
Review URL: https://codereview.chromium.org/11635031
|
|
Without this, the load would not be RIP relative, and will end up
being relative to 0, which is R15.
BUG= http://code.google.com/p/nativeclient/issues/detail?id=3219
TEST= ./scons bitcode=1 pnacl_generate_pexe=0 \
run_stack_frame_noopt_noframe_test \
run_unwind_trace_noopt_noframe_test \
run_stack_frame_noopt_frame_test \
run_unwind_trace_noopt_frame_test \
platform=x86-64 nacl_pic=1
Review URL: https://codereview.chromium.org/11575042
|
|
If the addressing mode matches certain patterns, then FastISel for the
instruction is rejected and regular ISel is used, where
X86DAGToDAGISel::LegalizeAddressingModeForNaCl() does the necessary
transformations.
The most common problem (which shows up in spec2k gcc and crafty) is
when a register holds a negative offset indexing an interior pointer
into a global struct/array, e.g. global_var[10+reg] where
&global_var[10] is a precomputed constant and reg is negative.
BUG= http://code.google.com/p/nativeclient/issues/detail?id=3211
TEST= On the x86-64 platform, run 176.gcc from spec2k with FastISel
forced, e.g. by modifying pnacl-translate.py to set default
FAST_TRANSLATION=1 and uncommenting the "-fast-isel" flag in the
LLC_FLAGS_FAST_X8664 definition.
Review URL: https://codereview.chromium.org/11543023
|
|
really needed in getOrCreateDataFragment.
BUG=none
Review URL: https://codereview.chromium.org/11534017
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169803 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
try to reduce the width of this load, and would end up transforming:
(truncate (lshr (sextload i48 <ptr> as i64), 32) to i32)
to
(truncate (zextload i32 <ptr+4> as i64) to i32)
We lost the sext attached to the load while building the narrower i32
load, and replaced it with a zext because lshr always zext's the
results. Instead, bail out of this combine when there is a conflict
between a sextload and a zext narrowing. The rest of the DAG combiner
still optimize the code down to the proper single instruction:
movswl 6(...),%eax
Which is exactly what we wanted. Previously we read past the end *and*
missed the sign extension:
movl 6(...), %eax
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169802 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This test case uses -mcpu=corei7 so it belongs in CodeGen/X86
Reviewed by: Nadav
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169801 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169798 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This shouldn't affect codegen for -O0 compiles as tail call markers are not
emitted in unoptimized compiles. Testing with the external/internal nightly
test suite reveals no change in compile time performance. Testing with -O1,
-O2 and -O3 with fast-isel enabled did not cause any compile-time or
execution-time failures. All tests were performed on my x86 machine.
I'll monitor our arm testers to ensure no regressions occur there.
In an upcoming clang patch I will be marking the objc_autoreleaseReturnValue
and objc_retainAutoreleaseReturnValue as tail calls unconditionally. While
it's theoretically true that this is just an optimization, it's an
optimization that we very much want to happen even at -O0, or else ARC
applications become substantially harder to debug.
Part of rdar://12553082
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169796 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
controls each of the abbreviation sets (only a single one at the
moment) and computes offsets separately as well for each set
of DIEs.
No real function change, ordering of abbreviations for the skeleton
CU changed but only because we're computing in a separate order. Fix
the testcase not to care.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169793 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1. Teach it to use overlapping unaligned load / store to copy / set the trailing
bytes. e.g. On 86, use two pairs of movups / movaps for 17 - 31 byte copies.
2. Use f64 for memcpy / memset on targets where i64 is not legal but f64 is. e.g.
x86 and ARM.
3. When memcpy from a constant string, do *not* replace the load with a constant
if it's not possible to materialize an integer immediate with a single
instruction (required a new target hook: TLI.isIntImmLegal()).
4. Use unaligned load / stores more aggressively if target hooks indicates they
are "fast".
5. Update ARM target hooks to use unaligned load / stores. e.g. vld1.8 / vst1.8.
Also increase the threshold to something reasonable (8 for memset, 4 pairs
for memcpy).
This significantly improves Dhrystone, up to 50% on ARM iOS devices.
rdar://12760078
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169791 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Analyse Phis under the starting assumption that they are NoAlias. Recursively
look at their inputs.
If they MayAlias/MustAlias there must be an input that makes them so.
Addresses bug 14351.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169788 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
InitSections is called before the MCContext is initialized it could cause
duplicate temporary symbols to be emitted later (after context initialization
resets the temporary label counter).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169785 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
beyond array bounds.
No test case since I cannot reproduce an ICE with this bug. According
to Carlos -- the bug reporter -- a segfault occurs only when LLVM is
compiled with a specific version of GCC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169783 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169779 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169774 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169773 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169772 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The linker will call `lto_codegen_add_must_preserve_symbol' on all globals that
should be kept around. The linker will pretend that a dylib is being created.
<rdar://problem/12528059>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169770 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
getMipsRegisterNumbering and use MCRegisterInfo::getEncodingValue instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169760 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
going on and makes a lot of the terminology in comments make more sense.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169758 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The `-mno-red-zone' flag wasn't being propagated to the functions that code
coverage generates. This allowed some of them to use the red zone when that
wasn't allowed.
<rdar://problem/12843084>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169754 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
while (i--)
sum+=A[i];
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169752 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
If the local checkout does not have 'git svn' references set up, don't try
to use 'git svn' for version information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169749 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the assembler. This is useful in order to know how the numbers add up,
since in particular the Align fragments account for a non-trivial
portion of the emitted fragments (especially on -O0 which sets
relax-all).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169747 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
misched used GetUnderlyingObject in order to break false load/store
dependencies, and the -enable-aa-sched-mi feature similarly relied on
GetUnderlyingObject in order to ensure it is safe to use the aliasing analysis.
Unfortunately, GetUnderlyingObject does not recurse through phi nodes, and so
(especially due to LSR) all of these mechanisms failed for
induction-variable-dependent loads and stores inside loops.
This change replaces uses of GetUnderlyingObject with GetUnderlyingObjects
(which will recurse through phi and select instructions) in misched.
Andy reviewed, tested and simplified this patch; Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169744 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PR14343
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169742 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Accidental commit... git svn betrayed me. Sorry for the noise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169741 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Not all chips targeted by x86_64 have this feature, but a dramatically
increasing number do. Specifying a chip-specific tuning parameter will
continue to turn the feature on or off as appropriate for that
particular chip, but the generic flag should try to achieve the best
performance on the most widely available hardware. Today, the number of
chips with fast UA access dwarfs those without in the x86-64 space.
Note that this also brings LLVM's code generation for this '-march' flag
more in line with that of modern GCCs.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D195
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169740 91177308-0d34-0410-b5e6-96231b3b80d8
|