[LLVMdev] [cfe-dev] TargetParser - Always build all table-gen files?
rnk at google.com
Mon Mar 9 11:21:44 PDT 2015
To be clear, TargetParser is about parsing subtarget CPUs and features,
I'm not very familiar with how the current system works, but it would be a
shame to run tablegen for all targets when the user just wants one backend.
The subtarget feature flags aren't very much data. If I were doing this
today, I would make one subtarget info library and put all the subtarget
features in there. The subtarget information is far less than the
instruction table information. For example:
Now that we have a lot of backends and lots of out of tree backends, this
might be too disruptive. The answer might be that we have to live with
duplicating the subtarget features in clang and building some kind of
sanity checking mechanism to keep them in sync.
On Mon, Mar 9, 2015 at 5:02 AM, Renato Golin <renato.golin at linaro.org>
> Hi Folks,
> I'm back looking at the target parser that we discussed last year, and
> I have some questions.
> There is no way I can create a target-independent parser in lib/Target
> without re-encoding all the information about the targets that we
> already have in the table-gen files on all targets' directories. Doing
> that would be folly.
> But building all targets by default goes against the current thinking,
> which I quite welcome and think we should not break it. We need to
> find a common ground.
> My idea is to build all table-gen files on all targets, but not build
> all targets' files and not include them in the final libraries /
> binaries. Since the table-gen'ed files don't end up there by
> themselves, only what we use from them (in the target parser) will be
> included in the final binaries.
> Does that sound like a good idea? If so, how would one go about doing
> that? I'm guessing it's a change solely in CMake files, and could be
> done independently of the target parser implementation, right?
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev