On Sun, 2024-03-10 at 12:05 +0100, Iain Buclaw wrote: > 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.
Sorry for the delay in responding. I don't want to be in the business of maintaining a copy of the per- target code for "jit", and I think it makes sense for libgccjit to return identical information compared to gccrs. So I think it would be ideal for jit to share code with rust for this, rather than do a one-time copy-and-paste followed by a ongoing "keep things updated" treadmill. Presumably there would be Makefile.in issues given that e.g. Makefile has i386-rust.o listed in: # Target specific, Rust specific object file RUST_TARGET_OBJS= i386-rust.o linux-rust.o One approach might be to move e.g. the i386-rust.cc code into, say, a i386-rust-and-jit.inc file and #include it from i386-rust.cc and i386- jit.cc (with a similar approach for other targets) Antoni, Arthur, would you each be OK with that? > 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. Also a question for Antoni and Arthur: is that desirable for the two gcc rust approaches? Thanks Dave
