Re: [RFA:] fix PR55030, wrong code from __builtin_setjmp_receiver

[Eric Botcazou <ebotcazou@adacore.com>]

> I was mainly arguing with the sentence that for asm volatile, the output
> constraints (did you mean outputs and clobbers?) have essentially no
> meaning.  While for some optimizations perhaps it might be desirable
> to treat asm volatile as full optimization barrier, I'm not sure about all
> of them (i.e. it would be important to look for performance degradations
> caused by that change), and for var-tracking I'd argue that asm vs. asm
> volatile is completely unimportant, if the asm volatile pattern (or even
> UNSPEC_VOLATILE) doesn't say it clobbers or sets hard register XYZ, then it
> can't change it (well, it could but is responsible of restoring it),
> similarly for memory, if it doesn't clobber "memory" and doesn't set some
> memory, it can't do that.

Yes, I meant outputs and clobbers.  The origin of all this is:

`blockage'
     This pattern defines a pseudo insn that prevents the instruction
     scheduler and other passes from moving instructions and using
     register equivalences across the boundary defined by the blockage
     insn.  This needs to be an UNSPEC_VOLATILE pattern or a volatile
     ASM.

Now the typical blockage insn is that of the x86:

;; UNSPEC_VOLATILE is considered to use and clobber all hard registers and
;; all of memory.  This blocks insns from being moved across this point.

(define_insn "blockage"
  [(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)]
  ""
  ""
  [(set_attr "length" "0")])

[Note the pretty adamant comment about UNSPEC_VOLATILE here...]

So, if UNSPEC_VOLATILE is not treated specially, the blockage insn of most 
ports won't block hard register equivalences.  And blockages are precisely 
used to do that, see e.g. the untyped_call pattern of the x86:

  /* The optimizer does not know that the call sets the function value
     registers we stored in the result block.  We avoid problems by
     claiming that all hard registers are used and clobbered at this
     point.  */
  emit_insn (gen_blockage ());

That being said, I agree that volatile asms are a separate discussion.

> So, do you object even to the var-tracking change (which would mean if
> var-tracking found that say some variable's value lives in hard register 12,
> when encountering asm volatile it would mean to forget about that even when
> hard register 12 isn't clobbered by the asm, nor set)?  For now
> var-tracking seems to be the most important issue, as we generate invalid
> debug info there (latent before, but never hit on inline asm on x86_64/i686
> except on setjmp calls).

For volatile asms, no, thanks for fixing the fallout on this side.

> As for other passes, the r193802 change e.g. regresses slightly modified
> pr44194-1.c testcase on x86_64,
> struct ints { int a, b, c; } foo();
> void bar(int a, int b);
> 
> void func() {
>   struct ints s = foo();
>   int x;
>   asm volatile ("" : "=r" (x));
>   bar(s.a, s.b);
> }
> 
>  func:
>  .LFB0:
> -	xorl	%eax, %eax
>  	subq	$24, %rsp
>  .LCFI0:
> +	xorl	%eax, %eax
>  	call	foo
> -	movq	%rax, %rcx
> -	shrq	$32, %rcx
> -	movq	%rcx, %rsi
> -	movl	%eax, %edi
> +	movq	%rax, (%rsp)
> +	movl	%edx, 8(%rsp)
> +	movl	4(%rsp), %esi
> +	movl	(%rsp), %edi
>  	addq	$24, %rsp
>  .LCFI1:
>  	jmp	bar
> 
> To me it looks like an unnecessary pessimization, the volatile there
> I understand that just it doesn't want to be moved around (e.g. scheduled
> before the foo call or after bar), that it can't be DCEd, but as it doesn't
> mention it modifies memory, I don't understand why it should force some
> registers to stack and back when it has no way to know the compiler would be
> emitting anything like that at all.
> Compare that to
>   asm volatile ("" : "=r" (x) : : "memory");
> in the testcase, where the r193802 commit makes no difference, the
> stores/loads are done in both cases.

OK, I agree that the fallout for DSE, and the effect on memory in general, is 
undesirable, especially for volatile asms.

> For CSE, I'd agree it should treat asm volatile as barriers, so for cselib.c
> we probably need some additional cselib_init flag how we want to treat
> volatile asms...  For UNSPEC_VOLATILE, perhaps even DSE should stay
> conservative, but for var-tracking.c I still don't see a reason for that.

Thank you (as well as the others) for the detailed feedback.  Clearly my 
initial stance on this was a bit extreme and needs to be watered down.
I'll ponder about this over the week-end and propose something next week.

-- 
Eric Botcazou