| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 304928
|
|
|
|
| |
llvm-svn: 304878
|
|
|
|
| |
llvm-svn: 304264
|
|
|
|
|
|
|
|
| |
A recent commit made GlobalVariable.h depend on intrinsics generation, so (I
think) it needs to be in the lower-level module. I'll confirm with others, but
this should fix the bots.
llvm-svn: 302803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
object that knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
The problem with the previous commit appears to have been that TableGen was including CodeGen/LowLevelType.h instead of Support/LowLevelTypeImpl.h.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297241
|
|
|
|
|
|
|
|
|
|
| |
More module problems. This time it only showed up in the stage 2 compile of
clang-x86_64-linux-selfhost-modules-2 but not the stage 1 compile.
Somehow, this change causes the build to need Attributes.gen before it's been
generated.
llvm-svn: 297188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297177
|
|
|
|
|
|
| |
Add WasmRelocs/WebAssembly.def to textual include header.
llvm-svn: 296356
|
|
|
|
| |
llvm-svn: 291079
|
|
|
|
|
|
| |
<rdar://problem/29247092>
llvm-svn: 286930
|
|
|
|
| |
llvm-svn: 285730
|
|
|
|
|
|
|
|
| |
Our modules support seems to be able to handle them nowadays.
Patch by Cristina Cristescu!
llvm-svn: 281340
|
|
|
|
| |
llvm-svn: 277267
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22769
llvm-svn: 276669
|
|
|
|
| |
llvm-svn: 275657
|
|
|
|
|
|
| |
Follow on to r275312.
llvm-svn: 275319
|
|
|
|
|
|
|
|
| |
As per Richard Smith, this should help avoid a modules bug exposed
by my r275216 commit:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/17560
llvm-svn: 275312
|
|
|
|
|
|
|
|
|
| |
This reapplies r274313 with two additional #include directives needed
when submodule visibility is enabled.
Fixes PR28384.
llvm-svn: 274358
|
|
|
|
|
|
|
|
| |
This reverts commit r274313.
While this fixed the build on Darwin, it broke Linux with local submodule
visibility.
llvm-svn: 274328
|
|
|
|
|
|
| |
This fixes the -fmodules build.
llvm-svn: 274313
|
|
|
|
|
|
|
|
|
|
| |
Some headers in IR depend on tablegen generated code. Modules builds triggered
generation of the LLVM_IR module (including headers dependant on intrinsic_gen),
imposing a unnecessary build dependency.
Reviewed by Richard Smith.
llvm-svn: 274006
|
|
|
|
| |
llvm-svn: 273541
|
|
|
|
| |
llvm-svn: 273112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
module.
The header files are designed to be used always together (through Pass.h).
Addresses the first part of https://llvm.org/bugs/show_bug.cgi?id=27991
Patch by Cristina Cristescu and me.
Reviewed by Richard Smith.
llvm-svn: 272877
|
|
|
|
|
|
| |
workaround from module map.
llvm-svn: 272612
|
|
|
|
| |
llvm-svn: 270902
|
|
|
|
| |
llvm-svn: 269438
|
|
|
|
| |
llvm-svn: 263319
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17005
llvm-svn: 260186
|
|
|
|
|
|
| |
Missed this stuff in r259291.
llvm-svn: 259292
|
|
|
|
|
|
| |
module map.
llvm-svn: 257515
|
|
|
|
| |
llvm-svn: 251163
|
|
|
|
|
|
|
| |
to get away with this because llvm/Support/GCOV.h was an implementation detail
of the llvm-gcov tool, but it's now being used by FDO.
llvm-svn: 250258
|
|
|
|
|
|
|
| |
The former setup once resulted in us ignoring the module for C compilations,
but Clang now errors on this if the header is included from C code (which it is).
llvm-svn: 247377
|
|
|
|
| |
llvm-svn: 247359
|
|
|
|
|
|
| |
build.
llvm-svn: 240823
|
|
|
|
|
|
|
| |
Mark CodeGen/DIEValues.def as a textual inclusion to fix the
`LLVM_ENABLE_MODULES` build.
llvm-svn: 239794
|
|
|
|
| |
llvm-svn: 235666
|
|
|
|
| |
llvm-svn: 231532
|
|
|
|
| |
llvm-svn: 230427
|
|
|
|
| |
llvm-svn: 229591
|
|
|
|
| |
llvm-svn: 229243
|
|
|
|
|
|
| |
don't get included on systems where the DIA SDK is unavailable.
llvm-svn: 229200
|
|
|
|
|
|
| |
header.
llvm-svn: 229154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM's include tree and the use of using declarations to hide the
'legacy' namespace for the old pass manager.
This undoes the primary modules-hostile change I made to keep
out-of-tree targets building. I sent an email inquiring about whether
this would be reasonable to do at this phase and people seemed fine with
it, so making it a reality. This should allow us to start bootstrapping
with modules to a certain extent along with making it easier to mix and
match headers in general.
The updates to any code for users of LLVM are very mechanical. Switch
from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h".
Qualify the types which now produce compile errors with "legacy::". The
most common ones are "PassManager", "PassManagerBase", and
"FunctionPassManager".
llvm-svn: 229094
|
|
|
|
| |
llvm-svn: 226980
|
|
|
|
| |
llvm-svn: 224091
|
|
|
|
| |
llvm-svn: 222808
|
|
|
|
|
|
|
| |
has been modular since r206822, and excluding it was leading to workarounds
such as the one in r219592, which this change removes.
llvm-svn: 219593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code is buggy and barely tested. It is also mostly boilerplate.
(This includes MCObjectDisassembler, which is the interface to that
functionality)
Following an IRC discussion with Jim Grosbach, it seems sensible to just
nuke the whole lot of functionality, and dig it up from VCS if
necessary (I hope not!).
All of this stuff appears to have been added in a huge patch dump (look
at the timeframe surrounding e.g. r182628) where almost every patch
seemed to be untested and not reviewed before being committed.
Post-review responses to the patches were never addressed. I don't think
any of it would have passed pre-commit review.
I doubt anyone is depending on this, since this code appears to be
extremely buggy. In limited testing that Michael Spencer and I did, we
couldn't find a single real-world object file that wouldn't crash the
CFG reconstruction stuff. The symbolizer stuff has O(n^2) behavior and
so is not much use to anyone anyway. It seemed simpler to remove them as
a whole. Most of this code is boilerplate, which is the only way it was
able to scrape by 60% coverage.
HEADSUP: Modules folks, some files I nuked were referenced from
include/llvm/module.modulemap; I just deleted the references. Hopefully
that is the right fix (one was a FIXME though!).
llvm-svn: 216983
|