| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
This reverts commit r261899. Even though I am not yet 100% certain, this is
commit is the only one that has some relation to the recent cmake failures
in Polly.
llvm-svn: 262202
|
| |
|
|
|
|
| |
Enabling avx512vbmi or avx512ifma should enable avx512f. Add command line switches and header defines for avx512ifma and avx512vbmi.
llvm-svn: 262201
|
| |
|
|
|
|
| |
don't know why.
llvm-svn: 262200
|
| |
|
|
|
|
|
|
| |
OpenMP 4.5 allows to privatize non-static data members of current class
in non-static member functions. Patch adds initial parsing/semantic
analysis for data members support in 'reduction' clauses.
llvm-svn: 262199
|
| |
|
|
|
|
|
|
|
|
| |
specifications
Functions with an explicit exception specification have their behavior
dictated by the specification. The additional /EHc behavior only comes
into play if no exception specification is given.
llvm-svn: 262198
|
| |
|
|
|
|
| |
This matches behavior with MSVC.
llvm-svn: 262197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the PassBuilder.
These are really just stubs for now, but they give a nice API surface
that Clang or other tools can start learning about and enabling for
experimentation.
I've also wired up parsing various synthetic module pass names to
generate these set pipelines. This allows the pipelines to be combined
with other passes and have their order controlled, with clear separation
between the *kind* of canned pipeline, and the *level* of optimization
to be used within that canned pipeline.
The most interesting part of this patch is almost certainly the spec for
the different optimization levels. I don't think we can ever have hard
and fast rules that would make it easy to determine whether a particular
optimization makes sense at a particular level -- it will always be in
large part a judgement call. But hopefully this will outline the
expected rationale that should be used, and the direction that the
pipelines should be taken. Much of this was based on a long llvm-dev
discussion I started years ago to try and crystalize the intent behind
these pipelines, and now, at long long last I'm returning to the task of
actually writing it down somewhere that we can cite and try to be
consistent with.
Differential Revision: http://reviews.llvm.org/D12826
llvm-svn: 262196
|
| |
|
|
| |
llvm-svn: 262195
|
| |
|
|
|
|
| |
The preload feature was buggy that we had disabled it even for ELF.
llvm-svn: 262194
|
| |
|
|
| |
llvm-svn: 262193
|
| |
|
|
|
|
|
|
| |
Because the class is used only by one instance, we do not have to
use template there in DriverTest.h. Everything can be moved to
DarwinLdDriverTest.cpp.
llvm-svn: 262192
|
| |
|
|
| |
llvm-svn: 262191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
UniversalDriver was used as a dispatcher to each platform-specific driver.
It had its own Options.td file. It was not just too much to parse only a
few options (we only want to parse -core, -flavor or argv[0]),
but also interpreted arguments too early. For example, if you invoke lld as
"lld -flavor gnu ... -help", then you'd get the UniversalDriver's help
message instead of GnuDriver's. This patch eliminates the use of Options
from the dispatcher.
http://reviews.llvm.org/D17686
llvm-svn: 262190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we import a module that has a complete array type and one that has an
incomplete array type, the declaration found by name lookup might be the one with
the incomplete type, possibly resulting in rejects-valid.
Now, the name lookup prefers decls with a complete array types. Also,
diagnose cases when the redecl chain has array bound, different from the merge
candidate.
Reviewed by Richard Smith.
llvm-svn: 262189
|
| |
|
|
|
|
|
|
| |
for clang.
char AnalysisBase::ID should be declared as extern and defined in one module.
llvm-svn: 262188
|
| |
|
|
| |
llvm-svn: 262187
|
| |
|
|
|
|
|
|
| |
tweaks."
I'll rework soon.
llvm-svn: 262186
|
| |
|
|
|
|
| |
char AnalysisBase::ID should be declared as extern and defined in one module.
llvm-svn: 262185
|
| |
|
|
| |
llvm-svn: 262184
|
| |
|
|
| |
llvm-svn: 262183
|
| |
|
|
| |
llvm-svn: 262182
|
| |
|
|
| |
llvm-svn: 262181
|
| |
|
|
|
|
| |
Operand order seems to have changed, the new one is nicer.
llvm-svn: 262180
|
| |
|
|
|
|
| |
More API churn, experimental target got sad.
llvm-svn: 262179
|
| |
|
|
|
|
|
|
|
|
| |
Adds a number of constants, defined in the ARM EHABI spec, to the Clang
lib/Headers/unwind.h header. This is prerequisite for landing
http://reviews.llvm.org/D15781, as previously discussed there.
Patch by Timon Van Overveldt.
llvm-svn: 262178
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17685
llvm-svn: 262177
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17684
llvm-svn: 262176
|
| |
|
|
|
|
|
| |
It is easier to handle section filler data separately rather than
merging with section names.
llvm-svn: 262175
|
| |
|
|
| |
llvm-svn: 262174
|
| |
|
|
| |
llvm-svn: 262173
|
| |
|
|
| |
llvm-svn: 262172
|
| |
|
|
|
|
|
|
|
|
|
| |
IIUC, range was an experiment to see how N3350 would work in LLD.
It turned out it didn't get traction, and it is basically duplicate
of iterator_range in ADT. We have only two occurrences of range,
and all of them are easily rewritten without it.
http://reviews.llvm.org/D17687
llvm-svn: 262171
|
| |
|
|
| |
llvm-svn: 262170
|
| |
|
|
| |
llvm-svn: 262169
|
| |
|
|
| |
llvm-svn: 262168
|
| |
|
|
| |
llvm-svn: 262167
|
| |
|
|
| |
llvm-svn: 262166
|
| |
|
|
| |
llvm-svn: 262165
|
| |
|
|
| |
llvm-svn: 262164
|
| |
|
|
|
|
| |
It was ELF specific.
llvm-svn: 262163
|
| |
|
|
| |
llvm-svn: 262162
|
| |
|
|
| |
llvm-svn: 262161
|
| |
|
|
| |
llvm-svn: 262160
|
| |
|
|
| |
llvm-svn: 262159
|
| |
|
|
|
|
| |
I think it is clear by now that the new linker is viable.
llvm-svn: 262158
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17654
llvm-svn: 262157
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot.
See details in:
https://llvm.org/bugs/show_bug.cgi?id=26758
llvm-svn: 262156
|
| |
|
|
| |
llvm-svn: 262155
|
| |
|
|
|
|
| |
Part of PR26753.
llvm-svn: 262154
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The maximum private allocation for the whole GPU is 4G,
so the maximum possible index for a single workitem is the
maximum size divided by the smallest granularity for a dispatch.
This increases the number of known zero high bits, which
enables more offset folding. The maximum private size per
workitem with this is 128M but may be smaller still.
llvm-svn: 262153
|