On Tue, Aug 2, 2011 at 12:01 PM, Georg-Johann Lay <[email protected]> wrote:
> Richard Guenther wrote:
>> On Tue, Aug 2, 2011 at 10:48 AM, Mikael Pettersson <[email protected]> wrote:
>>> Hans-Peter Nilsson writes:
>>> > On Mon, 1 Aug 2011, Richard Henderson wrote:
>>> >
>>> > > On 08/01/2011 01:30 PM, Michael Walle wrote:
>>> > > > 1) function inlining
>>> > > > 2) deferred argument evaluation
>>> > > > 3) because our target has no barrel shifter, (arg >> 10) is emitted
>>> as a
>>> > > > function call to libgcc's __ashrsi3 (_in place_!)
>>> > > > 4) BAM! dead code elimination optimizes r8 assignment away because
>>> calli
>>> > > > may clobber r1-r10 (callee saved registers on lm32).
>>> > >
>>> > > I'm afraid the only solution I can think of is to force F1 out-of-line.
>>> >
>>> > Or another temporary - but the parameter should already have
>>> > that effect.
>>>
>>> It should, but doesn't. See PR48863 for similar breakage on ARM.
>>
>> On GIMPLE we don't see either the libcall nor those "dependencies".
>>
>> Don't use register vars.
>
> IMO such code is supposed to work, e.g. in order to write an interface
> to a non-ABI assembler function. In general this cannot be expressed
> by means of constraints because that would imply plethora of different
> constraints for each register/mode.
>
> From the documentation a user will expect that he wrote correct code
> and is not supposed to bother with GCC inerts like implicit library
> calls or GIMPLE or whatever.
Well. I suppose what is happening is that we expand from
register int a1 __asm__ (*edi);
register int a2 __asm__ (*eax);
int D.2700;
<bb 2>:
D.2700_2 = arg_1(D) >> 10;
a1 = 10;
a2 = D.2700_2;
__asm__ __volatile__("scall" : : "r" a1, "r" a2);
return;
and end up TERing D.2700_2 = arg_1(D) >> 10, materializing a
libcall after the setting of a1 and before the asm. To confirm that
try -fno-tree-ter. I don't see how we can easily avoid this without
exposing libcalls at the gimple level. Maybe disable TER if
we see any register variable use.
Richard.
> Johann
>
>> Richard.
>
>
>
