Needed to fix PR18303 to correctly re-encode the instruction if it
is relaxed.
We keep a copy of the MCSubtargetInfo to make sure that we are not
effected by future changes to the subtarget info coming from the
assembler (e.g. when parsing .code 16 directived).
llvm-svn: 200347
When simplifycfg moves an instruction, it must drop metadata it doesn't know
is still valid with the preconditions changes. In particular, it must drop
the range and tbaa metadata.
The patch implements this with an utility function to drop all metadata not
in a white list.
llvm-svn: 200322
Mozilla and WebKit seem to use a space after @property (verified by
grepping their codebases) so we turn this on there as well.
Change by Christian Legnitto. Thank you!
llvm-svn: 200320
Express the strto* interceptors though macros. This removes a lot of
duplicate code and fixes a couple of copypasto bugs (where "res" was declared of
a different type than the actual return type). Also, add a few more interceptors
for strto*_l.
llvm-svn: 200316
Verification of base addresses is difficult as the independent blocks pass may
introduce aliasing that was not there during scop detection. As a midterm
solution -polly-codegen-scev will remove the need for the independent blocks
pass. For now, we do not verify at compile time that the independent blocks pass
does not make the base addresses loop invariant. Disabling this just removes
one of the multiple safety layers we have. We still can check for correctness
in our regression tests.
llvm-svn: 200315
Array base addresses need to be invariant in the region considered. The base
address has to be computed outside the region, or, when it is computed inside,
the value must not change with the iterations of the loops. For example, when a
two-dimensional array is represented as a pointer to pointers the base address
A[i] in an access A[i][j] changes with i; therefore, such regions have to be
rejected.
Contributed by: Armin Größlinger <armin.groesslinger@uni-passau.de>
llvm-svn: 200314
Make sure that we don't introduce illegal build_vector dag nodes
when trying to fold a sign_extend of a build_vector.
This fixes a regression introduced by r200234.
Added test CodeGen/X86/fold-vector-sext-crash.ll
to verify that llc no longer crashes with an assertion failure
due to an illegal build_vector of type MVT::v4i64.
Thanks to Ilia Filippov for spotting this regression and for
providing a reproducible test case.
llvm-svn: 200313
This change is a part of refactoring intended to have common signal handling behavior in all tools.
Note that this particular change doesn't enable use_sigaltstack support in every tool.
llvm-svn: 200310
Arguments and return values must always be marshalled as for the base
AAPCS when the callee is a variadic function.
Patch by Oliver Stannard!
llvm-svn: 200307
allow SIGABRT to spoil errno, because some real programs
reset SIGABRT handler in the handler, re-raise SIGABRT and return from the handler
llvm-svn: 200304
LLVM_REQUIRES_EH implies LLVM_REQUIRES_RTTI. It is as same behavior as Makefile.rule's.
llvm/examples/ExceptionDemo is affected. (It was built with -fno-rtti.)
For MSVC, Remove flags like "/EHsc /GR" in HandleLLVMOptions, or CL.EXE complains with flags like "/GR /GR-".
llvm_update_compile_flags() updates source file property if the target contains *.c.
COMPILE_FLAGS in target properties affects both C++ and C!
LLVM_NO_RTTI is deprecated. It was introduced by me and was my mistake.
llvm-svn: 200301
With this tweaks, also unittests are compiled with -ffunction-sections.
It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible.
llvm-svn: 200299
vectorizer, placing it behind an off-by-default flag.
It turns out that block frequency isn't what we want at all, here or
elsewhere. This has been I think a nagging feeling for several of us
working with it, but Arnold has given some really nice simple examples
where the results are so comprehensively wrong that they aren't useful.
I'm planning to email the dev list with a summary of why its not really
useful and a couple of ideas about how to better structure these types
of heuristics.
llvm-svn: 200294