search for: llvm_optimized_tablegen

...ere in the thread, building TableGen with > > Debug+Asserts isn't only useful for people who want to debug TableGen > > itself. It's useful for anybody modifying .td as many checks on .td > > input are only run in an asserts build. If there is a desire to move > > to LLVM_OPTIMIZED_TABLEGEN by default I think the correct next step is > > to write up a separate RFC on this, detailing the advantages, > > disadvantages, and potential paths forward. One of the obvious path > > forwards is to put development effort into ensuring that tablegen > > doesn't need as...

.... You would need to set it to off only if you want to debug tablegen. > > > I proposed this a while back, but it think there were some problems with it, I don't remember what exactly but maybe related to bootstrapping / 2-stages builds? > > + Chris, maybe he remembers something? LLVM_OPTIMIZED_TABLEGEN=ON is a handy way of speeding up build times, but it really shouldn't be recommended for anyone who is modifying .td files. You run the risk of making .td modifications that trigger asserts for those not using LLVM_OPTIMIZED_TABLEGEN. Best, Alex

...> > > > I proposed this a while back, but it think there were some problems > with > > it, I don't remember what exactly but maybe related to bootstrapping / 2- > > stages builds? > > > > > > + Chris, maybe he remembers something? > > > > LLVM_OPTIMIZED_TABLEGEN=ON is a handy way of speeding up build times, > > but it really shouldn't be recommended for anyone who is modifying .td > > files. You run the risk of making .td modifications that trigger > > asserts for those not using LLVM_OPTIMIZED_TABLEGEN. > > Can we make LLVM_OPT...

...hat was considered? As mentioned elsewhere in the thread, building TableGen with Debug+Asserts isn't only useful for people who want to debug TableGen itself. It's useful for anybody modifying .td as many checks on .td input are only run in an asserts build. If there is a desire to move to LLVM_OPTIMIZED_TABLEGEN by default I think the correct next step is to write up a separate RFC on this, detailing the advantages, disadvantages, and potential paths forward. One of the obvious path forwards is to put development effort into ensuring that tablegen doesn't need asserts enabled in order to catch invalid...

Historically there was a request to make LLVM_OPTIMIZED_TABLEGEN On by default for debug builds, which I discouraged. At the time it was suggested that workflow was fairly new and untested in a lot of build configurations. Today I believe that situation is slightly better. I believe there are still issues with it not working correctly in the Xcode generator, bu...

...generator). Pawel volunteered to take a look at the Visual Studio > situation. > I assume this is going to be the final plan we'll deploy unless > somebody comes with any fundamental objections or there are technical > hurdles down the road. > So, personally I feel strongly that LLVM_OPTIMIZED_TABLEGEN should be off by default, since the it splits up the ninja build graph. We've also run into issues with it with VS: https://reviews.llvm.org/D54153 Shelling out to `cmake --build` as part of a build action doesn't seem to work very well for many generators. What actually blocks us from re...

Hi Florian, Ok, I ran this: cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode Compiled it again from clean, and the situation is worse than before. Incremental builds take an incredible amount of time stuck in running Tablegen scripts for all targets. Now this happens both in Release and Debug configurations. Just before this, at least Release compiled fine, but...

Hi all, On LLVM version 7.0.1, incremental builds are very fast for both Release and Debug. I’m compiling with Xcode I recently downloaded LLVM 9.0 from the LLVM-mirror Github repository and found that Incremental "Debug” builds take a ridiculously long time due to Tablegen taking ages (literally more than 10 minutes) to generate files. This makes it totally unusable for debug purposes.

...ht  the website was kept up to date automagically, which is why I looked at the website not the source; but the source does have the new option.  Never mind… <> > > Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well. > > Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722 <https://reviews.llvm.org/rL353374#624722> > That seems like general badness in the way th...

...try building llvm as a shared objects.. > > On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi Florian, > > Ok, I ran this: > > cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode > > Compiled it again from clean, and the situation is worse than before. Incremental builds take an incredible amount of time stuck in running Tablegen scripts for all targets. Now this happens both in Release and Debug configurations. Just before this, at least Release compiled...

Probably not a blocker for replacing autoconf, while at it: Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio. It makes the tablegenning really slow. 2015-05-28 18:22 GMT+03:00 Chris Bieneman <beanz at apple.com>: > Hi all, > > Time for another update on the status of the CMake build system. > > Completed: > * Bug 18496 - [cmake] .S assembly files...

...ed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear. > Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well. Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722 <https://reviews.llvm.org/rL353374#624722> That seems like general badness in the way that configuration...

> On May 28, 2015, at 8:37 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Probably not a blocker for replacing autoconf, while at it: > Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio. > It makes the tablegenning really slow. This is actually a feature of the CMake build system that the autoconf one doesn’t have, so this is not related to replacing autoconf. That said, I’ll try to address this soon. -Chris > > > 2015-05-28 18:22...

...ed objects.. >> >> On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Hi Florian, >> >> Ok, I ran this: >> >> cmake -S LLVM -DCMAKE_INSTALL_PREFIX=INSTALL -DLLVM_OPTIMIZED_TABLEGEN=On -G Xcode >> >> Compiled it again from clean, and the situation is worse than before. Incremental builds take an incredible amount of time stuck in running Tablegen scripts for all targets. Now this happens both in Release and Debug configurations. Just before this, at least Release...

first: thank you for helping out >I might try compiling your source from the VS's Developer Command Prompt: >cmake --build . --target Fibonacci >Does this work? call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" cd llvm-build cmake --build . --config Debug --target Fibonacci building Fibonacci example works BUT

...tudio > >> situation. > >> I assume this is going to be the final plan we'll deploy unless > >> somebody comes with any fundamental objections or there are technical > >> hurdles down the road. > > > > > > So, personally I feel strongly that LLVM_OPTIMIZED_TABLEGEN should be > off by default, since the it splits up the ninja build graph. We've also > run into issues with it with VS: https://reviews.llvm.org/D54153 > Shelling out to `cmake --build` as part of a build action doesn't seem to > work very well for many generators. > > &gt...

...icularly true in cases when something in Support or ADT is modified, as > this usually triggers recompilation of large parts of LLVM. > Tablegen built in debug is really slow though, I remember an out-of-tree backend where running llvm-tblgen was taking up to 5 min per file! The CMake option LLVM_OPTIMIZED_TABLEGEN helps a lot with this. Otherwise LLVM_TABLEGEN is even more efficient, but it's a double-edged sword. But we could also use the diff-and-copy approach not on the tablegen output but on the llvm-tblgen binary itself, that way we wouldn't re-run it when it does not change itself (I'm not...

On Tue, Nov 26, 2019 at 10:31 AM David Jones via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Throw hardware at it. > While I agree that this is good advice with the current state of affairs, I don't think we should consider the current situation acceptable. LLVM has a lot of knobs that Tim alluded to, but first time users shouldn't have to search for them to get a

On Tue, May 30, 2017 at 12:52 PM Bob Haarman <llvm at inglorion.net> wrote: > I would like to better understand how you came to conclude that the > tablegen re-runs based on changes in Support are what's causing your build > to be slow and what part specifically is taking all that time. I can do a > clean release + assertions build of LLVM, Clang, compiler-rt and lld in >

Thanks! 2015-05-28 18:56 GMT+03:00 Chris Bieneman <beanz at apple.com>: > > On May 28, 2015, at 8:37 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Probably not a blocker for replacing autoconf, while at it: > Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio. > It makes the tablegenning really slow. > > > This is actually a feature of the CMake build system that the autoconf one > doesn’t have, so this is not related to replacing autoconf. > > That said, I’ll try to address this soon. > > -Chr...