ping?
Thanks,
Kugan
On 02/06/15 09:14, Kugan wrote:
>
>
> 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
>
