Introduces these negation forms explicitly and uses them to control a new
"altivec" target feature for PowerPC. This allows avoiding generating
Altivec instructions on processors that support Altivec.
The new test case verifies that the Altivec "lvx" instruction is not
used when -fno-altivec is present on the command line.
llvm-svn: 174140
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174055
Indents were given the color blue when outputting with color.
AST dumping now looks like this:
Node
|-Node
| `-Node
`-Node
`-Node
Compared to the previous:
(Node
(Node
(Node))
(Node
(Node)))
llvm-svn: 174022
implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.
The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed.
llvm-svn: 173848
One of the gotchas (see changes to CodeGenFunction) was due to the fix in
r139416 (for PR10829). This only worked previously because the top level
lexical block would set the location to the end of the function, the debug
location would be updated (as per r139416), the location would be set to
the end of the function again (but that would no-op, since it was the same
as the previous location), then the return instruction would be emitted using
the debug location.
Once the top level lexical block was no longer emitted, the end-of-function
location change was causing the debug loc to be updated, regressing that bug.
llvm-svn: 173593
Title: [PR9027] volatile struct bug: member is not loaded at -O;
This is caused by last flag passed to @llvm.memcpy being false,
not honoring that aggregate has at least one 'volatile' data member
(even though aggregate itself has not been qualified as 'volatile'.
As a result, optimization optimizes away the memcpy altogether.
Patch review by John MaCall (I still need to fix up a test though).
llvm-svn: 173535
This is a missing piece for C99 conformance.
This patch handles UCNs by adding a '\\' case to LexTokenInternal and
LexIdentifier -- if we see a backslash, we tentatively try to read in a UCN.
If the UCN is not syntactically well-formed, we fall back to the old
treatment: a backslash followed by an identifier beginning with 'u' (or 'U').
Because the spelling of an identifier with UCNs still has the UCN in it, we
need to convert that to UTF-8 in Preprocessor::LookUpIdentifierInfo.
Of course, valid code that does *not* use UCNs will see only a very minimal
performance hit (checks after each identifier for non-ASCII characters,
checks when converting raw_identifiers to identifiers that they do not
contain UCNs, and checks when getting the spelling of an identifier that it
does not contain a UCN).
This patch also adds basic support for actual UTF-8 in the source. This is
treated almost exactly the same as UCNs except that we consider stray
Unicode characters to be mistakes and offer a fixit to remove them.
llvm-svn: 173369
the 64-bit PowerPC ELF ABI.
The ABI requires that the real and imaginary parts of a complex argument
each occupy their own doubleword. Arguments smaller than 8 bytes are
right-adjusted within the doubleword.
Clang expects EmitVAARG() to return a pointer to a structure in which
the real and imaginary parts are packed adjacently in memory. To accomplish
this, we generate code to load the code appropriately from the varargs
location and pack the values into a temporary variable in the form Clang
expects, returning a pointer to that structure.
The test case demonstrates correct code generation for all "small" complex
types on PPC64: int, short, char, and float.
llvm-svn: 172438
with respect to the lower "left-hand-side bitwidth" bits, even when negative);
see OpenCL spec 6.3j. This patch both implements this behaviour in the code
generator and "constant folding" bits of Sema, and also prevents tests
to detect undefinedness in terms of the weaker C99 or C++ specifications
from being applied.
llvm-svn: 171755
When we are visiting the extern declaration of 'i' in
static int i = 99;
int foo() {
extern int i;
return i;
}
We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.
Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.
Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.
Thanks to Reed Kotler for reporting this.
llvm-svn: 170827
PR 14529 was opened because neither Clang or LLVM was expanding
calls to creal* or cimag* into instructions that just load the
respective complex field. After some discussion, it was not
considered realistic to do this in LLVM because of the platform
specific way complex types are expanded. Thus a way to solve
this in Clang was pursued. GCC does a similar expansion.
This patch adds the feature to Clang by making the creal* and
cimag* functions library builtins and modifying the builtin code
generator to look for the new builtin types.
llvm-svn: 170455
incompatibility with how complex values are returned. It is sufficient
to flag all complex types as direct rather than indirect.
A new test case is provided that checks correct IR generation for the
various supported flavors of _Complex.
llvm-svn: 170302
My variadics patch, r169588, changed these calls to typically be
bitcasts rather than calls to a supposedly variadic function.
This totally subverted a hack where we intentionally dropped
excess arguments from such calls in order to appease the inliner
and a "warning" from the optimizer. This patch extends the hack
to also work with bitcasts, as well as teaching it to rewrite
invokes.
llvm-svn: 170034
We were emitting calls to blocks as if all arguments were
required --- i.e. with signature (A,B,C,D,...) rather than
(A,B,...). This patch fixes that and accounts for the
implicit block-context argument as a required argument.
In addition, this patch changes the function type under which
we call unprototyped functions on platforms like x86-64 that
guarantee compatibility of variadic functions with unprototyped
function types; previously we would always call such functions
under the LLVM type T (...)*, but now we will call them under
the type T (A,B,C,D,...)*. This last change should have no
material effect except for making the type conventions more
explicit; it was a side-effect of the most convenient implementation.
llvm-svn: 169588
generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.
The primary change this introduces is to move from a manually aligned
and strided access pattern across the bits of the bitfield to a much
simpler lump access of all bits in the bitfield followed by math to
extract the bits relevant for the particular field.
This simplifies the code significantly, but relies on LLVM to
intelligently lowering these integers.
I have tested LLVM's lowering both synthetically and in benchmarks. The
lowering appears to be functional, and there are no really significant
performance regressions. Different code patterns accessing bitfields
will vary in how this impacts them. The only real regressions I'm seeing
are a few patterns where the LLVM code generation for loads that feed
directly into a mask operation don't take advantage of the x86 ability
to do a smaller load and a cheap zero-extension. This doesn't regress
any benchmark in the nightly test suite on my box past the noise
threshold, but my box is quite noisy. I'll be watching the LNT numbers,
and will look into further improvements to the LLVM lowering as needed.
llvm-svn: 169489
the output size is greater than the register size. No truncation occurs with
those. Reword warning to make it clearer what's the problem is.
llvm-svn: 169054
the original parameter or return type.
Since we do not accurately represent the data fields of a union, we should not
directly load or store a union type.
As an exmple, if we have i8,i8, i32, i32 as one field type and i32,i32 as
another field type, the first field type will be chosen to represent the union.
If we load with the union's type, the 3rd byte and the 4th byte will be skipped.
rdar://12723368
llvm-svn: 168820
string literal needs cleaning (because it contains line-splicing in the
encoding prefix or in the ud-suffix), do not clean the section between the
double-quotes -- that's the "raw" bit!
llvm-svn: 168776
ELF ABI.
Complex values are to be passed in registers as though the real and
imaginary parts were passed as separate parameters. Prior to this
patch, complex values were passed as byval aggregates. It turns out
that specifying getDirect() for all complex types when classifying the
argument type results in the desired behavior.
The new Clang test case verifies that the correct LLVM IR is generated
for caller and callee for each of the underlying types for _Complex.
llvm-svn: 168673
type as written from the ParmVarDecl; it's unclear whether the standard
(C99 6.9.1p10) requires this, but we're following the precedent set by gcc,
and hopefully nobody will ever ask about this again.
PR9559 / <rdar://problem/12621983>.
llvm-svn: 167985
If we have a type 'int a[1]' and a type 'int b[0]', the generated DWARF is the
same for both of them because we use the 'upper_bound' attribute. Instead use
the 'count' attrbute, which gives the correct number of elements in the array.
<rdar://problem/12566646>
llvm-svn: 167807
The 'a', 'c', and 'd' constraints on i386 mean a 32-bit register. We cannot
place a 64-bit value into the 32-bit register. Error out instead of causing the
compiler to spew general badness.
<rdar://problem/12415959>
llvm-svn: 167717
- New options '-mrtm'/'-mno-rtm' are added to enable/disable RTM feature
- Builtin macro '__RTM__' is defined if RTM feature is enabled
- RTM intrinsic header is added and introduces 3 new intrinsics, namely
'_xbegin', '_xend', and '_xabort'.
- 3 new builtins are added to keep compatible with gcc, namely
'__builtin_ia32_xbegin', '__builtin_ia32_xend', and '__builtin_ia32_xabort'.
- Test cases for pre-defined macro and new intrinsic codegen are added.
llvm-svn: 167665
disabling byval, we set realign to true.
It will perform an aligned alloca, and call memcpy to copy the byval
argument to the local variable.
Change the size threshold back to 64 bytes.
rdar://12596507
llvm-svn: 167440
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
llvm-svn: 167413
zero-extended to 64 bits. This information is currently provided to
the back end by setting "signext" or "zeroext" attributes. However,
this is done only for integer types *smaller* than i32, not for i32
itself. This causes clang to generate code violating the ABI, which
results in a failure of the tramp3d-v4 test case (due to calling a
system library routine without ABI-required extension).
This patch implements custom versions of classifyArgumentType and
classifyReturnType for PPC64_SVR4_ABIInfo, which are the same as the
default versions except that they also classify "int" and "unsigned int"
as types needing extending. This fixed tramp3d-v4 on PowerPC64.
llvm-svn: 167393
We want the diagnostic, and if the load is optimized away, we still want to
trap it. Stop checking non-default address spaces; that doesn't work in
general.
llvm-svn: 167219
If HA can only partially fit into VFP registers, we add padding to make sure
HA will be on stack and later VFP CPRCs will be on stack as well.
llvm-svn: 167058
ELF subtarget.
The existing description string is moved from PPC64TargetInfo to its
DarwinTargetInfo subclass, to avoid any changes to the Darwin ABI.
PPC64TargetInfo now has two possible description strings: one for FreeBSD,
which requires 8-byte alignment, and a default string that requires
16-byte alignment.
I've added a test for PPC64 Linux to verify the 16-byte alignment. If
somebody wants to add a separate test for FreeBSD, that would be great.
Note that there is a companion patch to update the alignment information
in LLVM, which I am committing now as well.
llvm-svn: 166927
varargs parameter passing.
A strict reading of the ABI indicates that any argument with alignment greater
than 8 may require skipping doublewords in the parameter save area to align
the argument, and hence require skipping GPRs. In practice, this is not done
by GCC. The alignment restriction is used for internal alignment of a
structure, but a structure with 16-byte alignment, for example, is not
itself 16-byte aligned in the parameter save area. Although this is messy,
it has become the de facto standard used in building existing libraries.
My initial varargs support followed the ABI language, but not the de facto
standard. Running the GCC compatibility test suite exposed this issue, and
indeed showed that LLVM didn't pass parameters self-consistently with my
original logic. Removing the additional alignment logic allows the affected
tests to now pass.
I modified the ppc64-varargs-struct.c test case to remove the existing test
for generation of alignment code, which is no longer appropriate.
Built and tested on powerpc64-unknown-linux-gnu with no new regressions.
llvm-svn: 166805
This code checks the ASM string to see if the output size is able to fit within
the variable specified as the output. For instance, scalar-to-vector conversions
may not really work. It's on by default, but can be turned off with a flag if
you think you know what you're doing.
This is placed under a flag ('-Wasm-operand-widths') and flag group ('-Wasm').
<rdar://problem/12284092>
llvm-svn: 166737
will be represented in the IR as a plain "i32" type. This causes the
tests to spuriously fail on platforms where int is not a 32-bit type,
or where the ABI requires attributes like "signext" or "zeroext" to
be used.
This patch adds -triple or -target parameters to force those tests
to use the i386-unknown-unknown target.
llvm-svn: 166551
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
llvm-svn: 166236
Because PNaCl bitcode must be target-independent, it uses some
different bitcode representations from other targets (e.g. byval and
sret for structures). This means that without additional type
information, it cannot meet some native ABI requirements for some
targets (e.g. passing structures containing unions by value on
x86-64). To allow generation of code which uses the correct native
ABIs, we also support triples such as x86_64-nacl, which uses
target-dependent IR (as opposed to le32-nacl, which uses byval and
sret).
To allow interoperation between the two types of code, this patch adds
a calling convention attribute to be used in code compiled with the
target-dependent triple, which will generate code using the le32-style
bitcode. This calling convention does not need to be explicitly
supported in the backend because it determines bitcode representation
rather than native conventions (the backend just needs to undersand
how to handle byval and sret for the Native Client OS).
This patch implements __attribute__((pnaclcall)) to generate calls in
bitcode according to the le32 bitcode conventions, an attribute which
is accepted by any Native Client target, but issues a warning
otherwise.
llvm-svn: 166065
Bill Schmidt