Our newly aggressive constant folding logic makes it possible for
CGExprConstant to see the same CompoundLiteralExpr more than once. So,
emitting a new GlobalVariable every time we see a CompoundLiteral is no
longer correct.
We had a similar issue with BlockExprs that was caught while testing
said aggressive folding, so I applied the same style of fix (see D26410)
here. If we find yet another case where this needs to happen, we should
probably refactor this so we don't have a third DenseMap+getter+setter.
As a design note: getAddrOfConstantCompoundLiteralIfEmitted is really
only intended to be called by ConstExprEmitter::EmitLValue. So,
returning a GlobalVariable* instead of a ConstantAddress costs us
effectively nothing, and saves us either a few bytes per entry in our
map or a bit of code duplication.
llvm-svn: 290661
to make reference to template parameters. This is only a partial
implementation; we retain the restriction that the argument must not be
type-dependent, since it's unclear how that would work given the existence of
other language rules requiring an exact type match in this context, even for
type-dependent cases (a question has been raised on the core reflector).
llvm-svn: 290647
This seems like it must've been a leftover by accident - no tests were
backing it up & it doesn't make much sense to include size/alignment on
class declarations (it'd only be on those declarations for which the
definition was available - otherwise the size/alignment would not be
known).
llvm-svn: 290631
Added \n commands to insert a line breaks where necessary, since one long line of documentation is nearly unreadable.
Formatted comments to fit into 80 chars.
In some cases added \a command in front of the parameter names to display them in italics.
llvm-svn: 290619
specialized than the primary template. (Put another way, if we imagine there
were a partial specialization matching the primary template, we should never
select it if some other partial specialization also matches.)
llvm-svn: 290593
template parameters of reference type basically doesn't work, because we're
always deducing from an argument expression of non-reference type, so the type
of the deduced expression never matches. Instead, compare the type of an
expression naming the parameter to the type of the argument.
llvm-svn: 290586
Windows uses PE/COFF which is inherently position independent. The use
of the PIC model is unnecessary. In fact, we would generate invalid
code using the ELF PIC model when PIC was enabled previously. Now that
we no longer accept -fPIC and -fpoc, this switches the internal
representation to the static model to permit us to make PIC modules
invalid when targeting Windows. This should not change the code
generation, only the internal state management.
llvm-svn: 290569
dependent contexts when processing the template in C++11 and C++14, just like
we do in C++98 and C++1z. This allows us to diagnose invalid templates earlier.
llvm-svn: 290567
Improved doxygen comments for the following intrinsics headers: __wmmintrin_pclmul.h, bmiintrin.h, emmintrin.h, f16cintrin.h, immintrin.h, mmintrin.h, pmmintrin.h, tmmintrin.h
Added \n commands to insert a line breaks where necessary, since one long line of documentation is nearly unreadable.
Formatted comments to fit into 80 chars.
In some cases added \a command in front of the parameter names to display them in italics.
llvm-svn: 290561
This is kind of funny because I specifically did work to make this easy
and then it didn't actually get implemented.
I've also ported a set of tests that rely on this functionality to run
with the new PM as well as the old PM so that we don't mess this up in
the future.
llvm-svn: 290558
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
llvm-svn: 290539
Use of these flags would result in the use of ELF-style PIE/PIC code
which is incorrect on Windows. Windows is inherently PIC by means of
the DLL slide that occurs at load. This also mirrors the behaviour on
GCC for MinGW. Currently, the Windows x86_64 forces the relocation
model to PIC (Level 2). This is unchanged for now, though we should
remove any assumptions on that and change it to a static relocation
model.
llvm-svn: 290533
non-type template parameters.
During partial ordering, when checking the substituted deduced template
arguments match the original, check the types of non-type template arguments
match even if they're dependent. The only way we get dependent types here is if
they really represent types of the other template (which are supposed to be
modeled as being substituted for unique, non-dependent types).
In order to make this work for auto-typed non-type template arguments, we need
to be able to perform auto deduction even when the initializer and
(potentially) the auto type are dependent, support for which is the bulk of
this patch. (Note that this requires the ability to deduce only a single level
of a multi-level dependent type.)
llvm-svn: 290511
This patch is to implement sema and parsing for 'target teams distribute' pragma.
Differential Revision: https://reviews.llvm.org/D28015
llvm-svn: 290508
The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall.
https://reviews.llvm.org/D22862
llvm-svn: 290505
Summary:
I needed to know whether a FieldDecl had an in-class
initializer for D26453. I used a narrowing matcher there, but a
traversal matcher might be generally useful.
Reviewers: sbenza, bkramer, klimek, aaron.ballman
Subscribers: aaron.ballman, Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D28034
llvm-svn: 290492
template arguments as written rather than the canonical template arguments,
so we print more user-friendly names for template parameters.
llvm-svn: 290483
Added \n commands to insert a line breaks where necessary to make the documentation more readable.
Formatted comments to fit into 80 chars.
llvm-svn: 290458
Tagged parameter names with \a doxygen command to display parameters in italics.
Added \n commands to insert a line break to make the documentation more readable.
Formatted comments to fit into 80 chars.
llvm-svn: 290455
manager, and a code path to use it.
The option is actually a top-level option but does contain
'experimental' in the name. This is the compromise suggested by Richard
in discussions. We expect this option will be around long enough and
have enough users towards the end that it merits not being relegated to
CC1, but it still needs to be clear that this option will go away at
some point.
The backend code is a fresh codepath dedicated to handling the flow with
the new pass manager. This was also Richard's suggested code structuring
to essentially leave a clean path for development rather than carrying
complexity or idiosyncracies of how we do things just to share code with
the parts of this in common with the legacy pass manager. And it turns
out, not much is really in common even though we use the legacy pass
manager for codegen at this point.
I've switched a couple of tests to run with the new pass manager, and
they appear to work. There are still plenty of bugs that need squashing
(just with basic experiments I've found two already!) but they aren't in
this code, and the whole point is to expose the necessary hooks to start
experimenting with the pass manager in more realistic scenarios.
That said, I want to *strongly caution* anyone itching to play with
this: it is still *very shaky*. Several large components have not yet
been shaken down. For example I have bugs in both the always inliner and
inliner that I have already spotted and will be fixing independently.
Still, this is a fun milestone. =D
One thing not in this patch (but that might be very reasonable to add)
is some level of support for raw textual pass pipelines such as what
Sean had a patch for some time ago. I'm mostly interested in the more
traditional flow of getting the IR out of Clang and then running it
through opt, but I can see other use cases so someone may want to add
it.
And of course, *many* features are not yet supported!
- O1 is currently more like O2
- None of the sanitizers are wired up
- ObjC ARC optimizer isn't wired up
- ...
So plenty of stuff still lef to do!
Differential Revision: https://reviews.llvm.org/D28077
llvm-svn: 290450
We shouldn't throw a warning when the static keyword is not present in
an anonymous namespace, just like we do for -Wmissing-prototypes.
llvm-svn: 290443
Summary:
We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir.
On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis.
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits
Differential Revision: https://reviews.llvm.org/D28048
llvm-svn: 290436
George Burgess IV