Age | Commit message (Collapse) | Author |
|
This is for the sandboxed llvm translator. Rough estimate,
from companion test:
https://codereview.chromium.org/12218141/
"""
Pruned out approx 35099 bytes worth of MCAsmParser symbols
Pruned out approx 49935 bytes worth of ::AsmParser symbols
Pruned out approx 183308 bytes worth of ARMAsmParser symbols
Pruned out approx 54552 bytes worth of X86AsmParser symbols
Pruned out approx 11415 bytes worth of ELFAsmParser symbols
Pruned out approx 7253 bytes worth of COFFAsmParser symbols
Pruned out approx 18450 bytes worth of DarwinAsmParser symbols
Pruned out approx 403 bytes worth of MCAsmLexer symbols
Pruned out approx 7009 bytes worth of ::AsmLexer symbols
Pruned out approx 359436 bytes worth of MatchTable symbols
"""
BUG= https://code.google.com/p/nativeclient/issues/detail?id=1222
Review URL: https://codereview.chromium.org/12218139
|
|
R=jvoung@chromium.org,eliben@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12302030
|
|
This results in trying to reference a negative offset from r15.
R=sehr@chromium.org,jvoung@chromium.org,eliben@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3302
Review URL: https://codereview.chromium.org/12277018
|
|
|
|
This avoids a use of the ParseIR/ParseIRFile API in the
sandboxed translator. ParseIR and friends are flexible and
handle LLVM .ll parsing. We only need to handle bitcode
streams... By removing a use of ParseIR*, LTO will remove
all LLParser-related code. Helps reduce the size of the
sandboxed LLC by a couple hundred KB.
Also, finally do the cleanup that makes the translator write
to its output file directly, rather than writing to a string
stream before finally writing the output to a file. May
save a couple of MB of memory (size of the object file)...
BUG= http://code.google.com/p/nativeclient/issues/detail?id=1222
Review URL: https://codereview.chromium.org/12224132
|
|
Ran all sandboxed translator tests for x86 and x64 locally.
BUG=https://code.google.com/p/nativeclient/issues/detail?id=3183
Review URL: https://codereview.chromium.org/12224110
|
|
1) Remove the ABIVerifyErrors class since it was just a wrapper with no real functionality. Replace with a simple string ostream for now. If in the future we want to have more intelligent error handling, we can come up with something that does what we actually decide we want.
2) When printing type errors in initializers, just print the Type that was invalid, rather than the whole initializer. This is implemented by having checkTypesInValue return the Type that was invalid, rather than just a boolean.
3) Check the type of each instruction (this is just to make sure it works from the function pass). Do not, however, make the passes dependent as in the previous CL (function passes cannot depend on module passes, but there are no checks for this, and opt does not enforce the dependence, and when llc tries to enforce it, very bad things happen)
2) Style cleanup to match LLVM style.
Sorry for the multiple changes in one CL, hopefully it's still small enough to be reviewable.
BUG=
Review URL: https://codereview.chromium.org/12224109
|
|
This allows properly implementing the analysis pass print() method, and
in the future will allow the error message to be sent somewhere useful
R=jvoung@chromium.org,eliben@chromium.org,mseaborn@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=2309
Review URL: https://codereview.chromium.org/12220028
|
|
|
|
|
|
|
|
|
|
Also, wrap some more debug code under the DEBUG() macro so that it gets
pruned with --disable-assertions.
BUG=none
Review URL: https://codereview.chromium.org/12162006
|
|
|
|
|
|
Conflicts:
include/llvm/CodeGen/IntrinsicLowering.h
include/llvm/MC/MCAssembler.h
include/llvm/MC/MCObjectStreamer.h
lib/LLVMBuild.txt
lib/Linker/LinkArchives.cpp
lib/MC/MCAssembler.cpp
lib/MC/MCELFStreamer.cpp
lib/MC/MCParser/AsmParser.cpp
lib/MC/MCPureStreamer.cpp
lib/MC/WinCOFFStreamer.cpp
lib/Makefile
lib/Support/Unix/Memory.inc
lib/Support/Unix/Process.inc
lib/Support/Unix/Program.inc
lib/Target/ARM/ARM.h
lib/Target/ARM/ARMFastISel.cpp
lib/Target/ARM/ARMISelLowering.cpp
lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
lib/Target/Mips/MipsInstrFPU.td
lib/Target/X86/CMakeLists.txt
lib/Target/X86/X86ISelLowering.cpp
lib/Target/X86/X86TargetMachine.cpp
lib/Target/X86/X86TargetObjectFile.cpp
lib/Transforms/InstCombine/InstCombineCalls.cpp
test/CodeGen/X86/fast-isel-x86-64.ll
tools/llc/llc.cpp
tools/lto/LTOModule.cpp
utils/TableGen/EDEmitter.cpp
|
|
The LOCALMOD from TargetFrameLowering was removed, so the base
constructor call localmod can be removed as well.
BUG=None
Review URL: https://codereview.chromium.org/12087037
|
|
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
|
|
into which we can emit single instructions without fixups (which is most
instructions). This is an optimization required because MCDataFragment
is prety large (240 bytes on x64), with no change in functionality.
For large programs, this reduces memory usage overhead required for bundling
by 40%.
To make the code as palatable as possible, the MCEncodedFragment interface was
further fragmented (no pun intended) and MCEncodedFragmentWithFixups is used
as the interface to work against when the user expects fixups. MCDataFragment
and MCRelaxableFragment implement this interface, while the new
MCCompactEncodedInstFragment implements MCEncodeFragment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172572 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// FIXME: Constraints are hard coded to 'm', but we need an 'r'
// constraint for addressof. This needs to be cleaned up!
Test cases are already in place. Specifically,
clang/test/CodeGen/ms-inline-asm.c t15(), t16(), and t24().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
After discussing the refactoring with Jim and Daniel, the following changes were
made:
* All generic directive parsing is now done by AsmParser itself. The previous
division between it and GenericAsmParser did not have clear boundaries and
just produced unnatural code of GenericAsmParser juggling the internals of
AsmParser through an interface.
The division of responsibilities is now clear: target-specific directives,
other extensions (used by platform-specific parseres), and generic directives.
* Priority for directive parsing was reshuffled to ask extensions first and
check the generic directives later.
No change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172568 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172556 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
some optimization opportunities (in the enclosing supper-expressions).
rule 1. (-0.0 - X ) * Y => -0.0 - (X * Y)
if expression "-0.0 - X" has only one reference.
rule 2. (0.0 - X ) * Y => -0.0 - (X * Y)
if expression "0.0 - X" has only one reference, and
the instruction is marked "noSignedZero".
2. Eliminate negation (The compiler was already able to handle these
opt if the 0.0s are replaced with -0.0.)
rule 3: (0.0 - X) * (0.0 - Y) => X * Y
rule 4: (0.0 - X) * C => X * -C
if the expr is flagged "noSignedZero".
3.
Rule 5: (X*Y) * X => (X*X) * Y
if X!=Y and the expression is flagged with "UnsafeAlgebra".
The purpose of this transformation is two-fold:
a) to form a power expression (of X).
b) potentially shorten the critical path: After transformation, the
latency of the instruction Y is amortized by the expression of X*X,
and therefore Y is in a "less critical" position compared to what it
was before the transformation.
4. Remove the InstCombine code about simplifiying "X * select".
The reasons are following:
a) The "select" is somewhat architecture-dependent, therefore the
higher level optimizers are not able to precisely predict if
the simplification really yields any performance improvement
or not.
b) The "select" operator is bit complicate, and tends to obscure
optimization opportunities. It is btter to keep it as low as
possible in expr tree, and let CodeGen to tackle the optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172551 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
verifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172550 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172549 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vectorization factor even if the target machine does not have any vector registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172544 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Some versions of gcc accept unsupported -W flags and run just fine if
there are no warnings, but die with an unsupported flag error if a
warning is encountered. gcc 4.3 and gcc 4.4 both exhibit this
behavior for -Wno-maybe-uninitialized. Therefore, if the flag check
for -Wno-maybe-uninitialized succeeds, only use
-Wno-maybe-uninitialized if we are using gcc version 4.7 or greater.
Use -Wno-uninitialized otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172543 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
They are failing on the bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172540 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also improve test coveration of the handling of relational comparisons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172539 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Both underlying IR operations support vectors of pointers already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172538 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It was out of sync with the conditions in the other two constructors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172535 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Test was failing for clang-native-arm-cortex-a9 build-bot configuration.
The reason for the failure was the test was using hardcoded names.
The attached patch fixes this failure by replacing the hard-coded variables
names with pattern-matched variable names.
Patch by Manish Verma, ARM
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172534 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172525 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This simplifies the usage and implementation of ELFObjectFile by using ELFType
to replace:
<endianness target_endianness, std::size_t max_alignment, bool is64Bits>
This does complicate the base ELF types as they must now use template template
parameters to partially specialize for the 32 and 64bit cases. However these
are only defined once.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Marks a decl as constexpr if the compiler supports it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172508 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
setting the InitialSize,
previously it was calling the "StringMapImpl(unsigned itemSize)" constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172499 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
- Also, update the LangRef documentation on module flags to match the
implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172498 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
we need to generate a N64 compound relocation
R_MIPS_GPREL_32/R_MIPS_64/R_MIPS_NONE.
The bug was exposed by the SingleSourcetest case
DuffsDevice.c.
Contributer: Jack Carter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172496 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
simply use the getParser method from MCAsmParserExtension, working through the
MCAsmParser interface. There's no longer a need to overload that method to
cast it to the concrete AsmParser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172491 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This finally allows AsmParser to no longer list GenericAsmParser as a friend.
All member vars directly accessed by GenericAsmParser have been properly
encapsulated and exposed through the MCAsmParser interface. This reduces the
coupling between AsmParser and GenericAsmParser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172490 91177308-0d34-0410-b5e6-96231b3b80d8
|