Excerpts from David Malcolm's message of März 5, 2024 4:09 pm: > On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote: >> Hi. >> See answers below. >> >> On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote: >> > On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote: >> > > Hi. >> > > This patch adds support for getting the CPU features in libgccjit >> > > (bug >> > > 112466) >> > > >> > > There's a TODO in the test: >> > > I'm not sure how to test that gcc_jit_target_info_arch returns >> > > the >> > > correct value since it is dependant on the CPU. >> > > Any idea on how to improve this? >> > > >> > > Also, I created a CStringHash to be able to have a >> > > std::unordered_set<const char *>. Is there any built-in way of >> > > doing >> > > this? >> > >> > Thanks for the patch. >> > >> > Some high-level questions: >> > >> > Is this specifically about detecting capabilities of the host that >> > libgccjit is currently running on? or how the target was configured >> > when libgccjit was built? >> >> I'm less sure about this part. I'll need to do more tests. >> >> > >> > One of the benefits of libgccjit is that, in theory, we support all >> > of >> > the targets that GCC already supports. Does this patch change >> > that, >> > or >> > is this more about giving client code the ability to determine >> > capabilities of the specific host being compiled for? >> >> This should not change that. If it does, this is a bug. >> >> > >> > I'm nervous about having per-target jit code. Presumably there's a >> > reason that we can't reuse existing target logic here - can you >> > please >> > describe what the problem is. I see that the ChangeLog has: >> > >> > > * config/i386/i386-jit.cc: New file. >> > >> > where i386-jit.cc has almost 200 lines of nontrivial code. Where >> > did >> > this come from? Did you base it on existing code in our source >> > tree, >> > making modifications to fit the new internal API, or did you write >> > it >> > from scratch? In either case, how onerous would this be for other >> > targets? >> >> This was mostly copied from the same code done for the Rust and D >> frontends. >> See this commit and the following: >> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b1c06fd9723453dd2b2ec306684cb806dc2b4fbb >> The equivalent to i386-jit.cc is there: >> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=22e3557e2d52f129f2bbfdc98688b945dba28dc9 > > [CCing Iain and Arthur re those patches; for reference, the patch being > discussed is attached to : > https://gcc.gnu.org/pipermail/jit/2024q1/001792.html ] > > One of my concerns about this patch is that we seem to be gaining code > that's per-(frontend x config) which seems to be copied and pasted with > a search and replace, which could lead to an M*N explosion. >
That's certainly the case with the configure/make rules. Itself I think is copied originally from the {cpu_type}-protos.h machinery. It might be worth pointing out that the c-family of front-ends don't have separate headers because their per-target macros are defined in {cpu_type}.h directly - for better or worse. > Is there any real difference between the per-config code for the > different frontends, or should there be a general "enumerate all > features of the target" hook that's independent of the frontend? (but > perhaps calls into it). > As far as I understand, the configure parts should all be identical between tm_p, tm_d, tm_rust, ..., so would benefit from being templated to aid any other front-ends adding in their own per target hooks. > Am I right in thinking that (rustc with default LLVM backend) has some > set of feature strings that both (rustc with rustc_codegen_gcc) and > gccrs are trying to emulate? If so, is it presumably a goal that > libgccjit gives identical results to gccrs? If so, would it be crazy > for libgccjit to consume e.g. config/i386/i386-rust.cc ? I don't know whether libgccjit can just pull in directly the implementation of the rust target hooks here. The per-frontend target hooks usually also make use of code specific to that front-end - TARGET_CPU_CPP_BUILTINS and others can't be used by a non-c-family front-end without adding a plethora of stubs, for example. Whether or not libgccjit wants to give identical information as as rust I think is a decision for you as the maintainer of its API. Iain.