On Thu, Sep 03, 2020 at 04:46:43PM -0300, Alexandre Oliva wrote:
> On Sep  3, 2020, Segher Boessenkool <seg...@kernel.crashing.org> wrote:
> > The idea is that none of them will need adjustment.  This hook runs
> > before the "none" code will run, and it can just clear all clobbers
> > then.
> 
> Uhh...  That's not how asm expansion works.  We process inputs, outputs,
> clobbers and labels first, *then* we pass all the cooked ops to the
> target hook, so that it gets a chance to, well, adjust stuff.

And after that you do the "none" stuff, not before!

> I don't think clobber "none" should disable target adjustments; IMHO, it
> should be recognized by target adjustments, and cause them to not add
> stuff they normally would.

Yeah, big thinko on my side there.  But my point remains: if we can do
this in generic code (and it looks like we can), don't do it in all 50+
targets (or the tennish affected ones) :-)

> > The user could want to use an empty asm to influence what code is
> > generated.  Yes, I know this isn't a very strong argument :-)
> 
> Well, it is to me, it's exactly what I'm doing here, you know? :-)

"I hadn't noticed yet".  Hehe.

> But it's not the kind of "things going wrong" that I was looking for.
> 
> > just set a flag and not call md_asm_adjust?
> 
> I don't like that.  When we move some asm processing between
> target-specific and generic, in either direction, suddenly "none"
> affects whether or not the processing gets done.  I don't like that.

But we do not *have* "none" in trunk yet (and so, of course also not in
any released GCC version, the important consideration).

Or you nmean something else that I don't see?

> > Maybe "nodefault" is a
> > better name than "none" btw
> 
> For that, I agree, but I don't think that's a good feature to have.  I'd
> rather have "none" and keep the ability to introduce target-specific
> adjustments à-la "=@cc*".  There's no good reason IMHO to have that hook
> disabled by "none" or by "nodefault".

"none" would disable all default *clobbers* only.  Not outputs.


Segher

Reply via email to