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.

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;

}

Thanks a lot for your time,
Kugan