Potential linearizer over simplication

Potential linearizer over simplication

[Dibyendu Majumdar]

Hi,

I am investigating a test that is failing. I noticed that the
linearized output for:

static double cbrtl (double x)
{
    int hx;
    double r,s,w;
    double lt;
    unsigned sign;
    union {
 double t;
 unsigned pt[2];
    } ut, ux;
    int n0;
    ut.t = 1.0;
    n0 = (ut.pt[0] == 0);
    ut.t = 0.0;
    ux.t = x;

is this:

cbrtl:
.L0:
 <entry-point>
 load.32     %r2 <- 0[ut]
 seteq.32    %r3 <- %r2, $0
 set.64      %r4 <- 0.000000
 store.64    %r4 -> 0[ut]
 store.64    %arg1 -> 0[ux]

The assignment of 1.0 to ut.t has been skipped. Does this look
correct? Is there a way to switch off optimisation / simplification?

Thanks and Regards
Dibyendu

Re: Potential linearizer over simplication

[Dibyendu Majumdar]

On 15 March 2017 at 00:00, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> I am investigating a test that is failing. I noticed that the
> linearized output for:
>
> static double cbrtl (double x)
> {
>     int hx;
>     double r,s,w;
>     double lt;
>     unsigned sign;
>     union {
>  double t;
>  unsigned pt[2];
>     } ut, ux;
>     int n0;
>     ut.t = 1.0;
>     n0 = (ut.pt[0] == 0);
>     ut.t = 0.0;
>     ux.t = x;
>
> is this:
>
> cbrtl:
> .L0:
>  <entry-point>
>  load.32     %r2 <- 0[ut]
>  seteq.32    %r3 <- %r2, $0
>  set.64      %r4 <- 0.000000
>  store.64    %r4 -> 0[ut]
>  store.64    %arg1 -> 0[ux]
>
> The assignment of 1.0 to ut.t has been skipped. Does this look
> correct? Is there a way to switch off optimisation / simplification?
>

Hi , investigating this further it seems that the problem is in
kill_dominated_stores(). The original sequence is:

        set.64      %r1 <- 1.000000
        store.64    %r1 -> 0[ut]
        load.32     %r2 <- 0[ut]
        seteq.32    %r3 <- %r2, $0
        store.32    %r3 -> 0[n0]
        set.64      %r4 <- 0.000000
        store.64    %r4 -> 0[ut]

As there is a load of 32 from 0[ut] and that value is then stored
somewhere else, the first store.64 instruction should mot be killed,
but this is being killed in the above mentioned function. I do not
understand the code enough to suggest a fix unfortunately.

Thanks and Regards
Dibyendu

Re: Potential linearizer over simplication

[Dibyendu Majumdar]

On 16 March 2017 at 11:16, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> On 15 March 2017 at 00:00, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>> I am investigating a test that is failing. I noticed that the
>> linearized output for:
>>
>> static double cbrtl (double x)
>> {
>>     int hx;
>>     double r,s,w;
>>     double lt;
>>     unsigned sign;
>>     union {
>>  double t;
>>  unsigned pt[2];
>>     } ut, ux;
>>     int n0;
>>     ut.t = 1.0;
>>     n0 = (ut.pt[0] == 0);
>>     ut.t = 0.0;
>>     ux.t = x;
>>
>> is this:
>>
>> cbrtl:
>> .L0:
>>  <entry-point>
>>  load.32     %r2 <- 0[ut]
>>  seteq.32    %r3 <- %r2, $0
>>  set.64      %r4 <- 0.000000
>>  store.64    %r4 -> 0[ut]
>>  store.64    %arg1 -> 0[ux]
>>
>> The assignment of 1.0 to ut.t has been skipped. Does this look
>> correct? Is there a way to switch off optimisation / simplification?
>>
>
> Hi , investigating this further it seems that the problem is in
> kill_dominated_stores(). The original sequence is:
>
>         set.64      %r1 <- 1.000000
>         store.64    %r1 -> 0[ut]
>         load.32     %r2 <- 0[ut]
>         seteq.32    %r3 <- %r2, $0
>         store.32    %r3 -> 0[n0]
>         set.64      %r4 <- 0.000000
>         store.64    %r4 -> 0[ut]
>
> As there is a load of 32 from 0[ut] and that value is then stored
> somewhere else, the first store.64 instruction should mot be killed,
> but this is being killed in the above mentioned function. I do not
> understand the code enough to suggest a fix unfortunately.
>

It seems that the fix might for dominates() to return -1 when it sees
loads and stores of different size rather than 0 as it does now.
Certainly this appears to fix this particular test case:

 if (!same_memop(insn, dom)) {
  if (dom->opcode == OP_LOAD)
   return -1; /* instead of 0 */
  if (!overlapping_memop(C, insn, dom))
   return 0;
  return -1;
 }

Re: Potential linearizer over simplication

[Luc Van Oostenryck]

On Wed, Mar 15, 2017 at 12:00:52AM +0000, Dibyendu Majumdar wrote:
> 
> The assignment of 1.0 to ut.t has been skipped. Does this look
> correct? Is there a way to switch off optimisation / simplification?

No, it's not correct.
Sparse do memops simplification wrongly, ignoring or at least
incorrectly taking aliasing in account.

-- Luc