On Sep 3, 2020, Segher Boessenkool <seg...@kernel.crashing.org> wrote:
> On Thu, Sep 03, 2020 at 07:03:53AM -0300, Alexandre Oliva wrote:
>> On Sep 2, 2020, Segher Boessenkool <seg...@kernel.crashing.org> wrote:
>> > (And aarch, but not the other targets with default clobbers).
>>
>> And arm. I didn't look very hard for others yet; I wasn't sure it would
>> be worth pursuing any further.
> Oh, I meant what was in your patch. From a grep, all of mn10300, nds32,
> arm, cris, pdp11, rs6000, i386, visium, aarch64 have default clobbers.
> Hrm, what you said was the targets with inline asm flag output
> constraints?
I found implicit cc clobbers on x86 only, and then I stumbled across the
same notation used for asm cc-setting in arm/aarch64, but that was all,
I didn't look any further (yet). I'll look at the other targets with
asm_adjust hooks and see whether they need adjustments for "none", if we
agree that's the way to go.
>> > People write empty asm statements not because they would like no insns
>> > emitted from it, but *because* they want the other effects an asm has
>> > (for example, an empty asm usually has no outputs, so it is volatile,
>> > and that makes sure it is executed in the real machine exactly as often
>> > as in the abstract machine). So your expectation might be wrong,
>> > someone might want an empty asm to clobber cc on x86 (like any asm is
>> > documented as doing).
>>
>> I just can't imagine a case in which flags set by an earlier
>> instruction, and that could be usable by a subsequent instruction, could
>> possibly be clobbered by an *empty* sequence of insns. Maybe I just
>> lack imagination about all the sorts of weird things that people use
>> such asm statements for... Got any example of something that could be
>> broken by such a change to educate me? Not that I need it, I'm just
>> curious.
> Before your change, flags could not be live through an asm.
While implementing this patchlet, I learned that standard asms (as
opposed to GCC-extended ones) only undergo machine-dependent adjustments
if their asm pattern string is non-empty. So there is precedent. I may
even have a finger on that precedent, from very long ago.
> After your change, it can. So it does change things...
No doubt it does change things, that's not the point. The point is how
could it break things. If the compiler can see flags are set before the
asm, and it can see the flags could be used after the asm, and the asm
has no code whatsoever in it that could possibly clobber the flags...
What could possibly go wrong? (Famous last words? :-)
>> > But how about a "none" clobber?
>>
>> I like that!
> Okay, sold! Now to convince everyone else ;-)
Here's a prototype implementation, x86 only. (ARM and Thumb do not add
any clobbers by default, so it's already good for "none") I haven't yet
looked at other targets. It's missing documentation and tests, too.
enable flags-unchanging asms
---
gcc/cfgexpand.c | 6 ++++++
gcc/config/i386/i386.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index b334ea0..f7ae789 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -2986,6 +2986,12 @@ expand_asm_stmt (gasm *stmt)
const char *regname = TREE_STRING_POINTER (TREE_VALUE (t));
int nregs, j;
+ if (i == 0 && strcmp (regname, "none") == 0)
+ {
+ clobber_rvec.safe_push (const0_rtx);
+ continue;
+ }
+
j = decode_reg_name_and_count (regname, &nregs);
if (j < 0)
{
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a15807d..2afff12 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -21142,7 +21142,7 @@ ix86_md_asm_adjust (vec<rtx> &outputs, vec<rtx>
&/*inputs*/,
rtx_insn *seq = get_insns ();
end_sequence ();
- if (saw_asm_flag)
+ if (saw_asm_flag || (clobbers.length () > 0 && clobbers[0] == const0_rtx))
return seq;
else
{
--
Alexandre Oliva, happy hacker
https://FSFLA.org/blogs/lxo/
Free Software Activist
GNU Toolchain Engineer
