Re: [RFC] Elimination of zext/sext - type promotion pass

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Jun 2, 2015 at 1:14 AM, Kugan <kugan.vivekanandarajah@linaro.org> wrote:
>

Sorry for replying so late...

> On 08/05/15 22:48, Richard Biener wrote:
>> You compute which promotions are unsafe, like sources/sinks of memory
>> (I think you miss call arguments/return values and also asm operands here).
>> But instead of simply marking those SSA names as not to be promoted
>> I'd instead split their life-ranges, thus replace
>>
>>   _1 = mem;
>>
>> with
>>
>>   _2 = mem;
>>   _1 = [zs]ext (_2, ...);
>>
>> and promote _1 anyway.  So in the first phase I'd do that (and obviously
>> note that _2 isn't to be promoted in the specific example).
>>
>> For promotions that apply I wouldn't bother allocating new SSA names
>> but just "fix" their types (assign to their TREE_TYPE).  This also means
>> they have to become anonymous and if they didn't have a !DECL_IGNORED_P
>> decl before then a debug stmt should be inserted at the point of the
>> promotions.  So
>>
>>   bar_3 = _1 + _2;
>>
>> when promoted would become
>>
>>  _4 = _1 + _2;
>>  _3 = sext <_4, ...>;
>>  # DEBUG bar = (orig-type) _4;  // or _3?
>>
>> so you'd basically always promote defs (you have a lot of stmt/operand
>> walking code I didn't look too closely at - but it looks like too much) and
>> the uses get promoted automagically (because you promote the original
>> SSA name). Promotion of constants has to remain, of course.
>
>
> Thanks Richard. I experimented on this idea to understand it better.
> Please see the attached prototype (I am still working on your other
> comments which is not addressed here). Please have a look and let me
> know if this is along what you would expect. I have few questions though.
>
> 1. In the following example above :
>   char _1;
>   _1 = mem;
>
> when changing with
>
>   char _2;
>   int _1;
>   _2 = mem;
>   _1 = [zs]ext (_2, ...);
>
> for the [zs]ext operation we now use BIT_AND_EXPR and ZEXT_EXPR which
> (as of now) requires that the LHS and RHS are of the same type. Are you
> suggesting that we should have a true ZEXT_EXPR and SEXT_EXPR which can
> do the above in the gimple? I am now using CONVER_EXPR and which is the
> source of many optimization issue.

You indeed need to use CONVERT_EXPR here, maybe you can elaborate
on the optimization issues.

> 2. for inline asm (a reduced test case that might not make much as a
> stand alone test-case, but I ran into similar cases with valid programmes)
>
> ;; Function fn1 (fn1, funcdef_no=0, decl_uid=4220, cgraph_uid=0,
> symbol_order=0)
>
> fn1 (short int p1)
> {
>   <bb 2>:
>   __asm__("" : "=r" p1_2 : "0" p1_1(D));
>   return;
>
> }
>
>
> I am generating something like the following which ICEs. What is the
> expected out?
>
> ;; Function fn1 (fn1, funcdef_no=0, decl_uid=4220, cgraph_uid=0,
> symbol_order=0)
>
> fn1 (short int p1)
> {
>   int _1;
>   int _2;
>   short int _5;
>
>   <bb 2>:
>   _1 = (int) p1_4(D);
>   _5 = (short int) _1;
>   __asm__("" : "=r" p1_6 : "0" _5);
>   _2 = (int) p1_6;
>   return;
>
> }

Parameters are indeed "interesting" to handle ;)  As we now see on ARM
the incoming parameter (the default def) and later assignments to it
can require different promotions (well, different extensions for ARM).

The only sensible way to deal with promoting parameters is to
promote them by changing the function signature.  Thus reflect the
targets ABI for parameters in the GIMPLE representation (which
includes TYPE_ARG_TYPES and DECL_ARGUMENTS).
IMHO we should do this during gimplification of parameters / call
arguments already.

So for your example you'd end up with

fn1 (int p1)
{
  __asm__("" : "=r" p1_6 : "0" p1_4(D));
  return;
}

that is, promotions also apply to asm inputs/outputs (no?)

Richard.

> Thanks a lot for your time,
> Kugan