Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)

[David Malcolm <dmalcolm@redhat.com>]

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