Another potential issue with linearized output

Another potential issue with linearized output

[Dibyendu Majumdar]

Hi,

When I try to compile following test (see link) in sparse-llvm - LLVM says:

Instruction does not dominate all uses!
  %load_target = load i32, i32* %191
  %R122 = icmp eq i32 %load_target4, %load_target
Instruction does not dominate all uses!
  %load_target = load i32, i32* %191
  %R283 = icmp eq i32 %load_target4, %load_target
Instruction does not dominate all uses!
  %load_target = load i32, i32* %191
  %R522 = icmp eq i32 %load_target4, %load_target

I have not yet investigated what the issue is but I thought it best to
post the test case so that it can be validated.

https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/bugs/cq3.c

Thanks and Regards

Dibyendu

Re: Another potential issue with linearized output

[Dibyendu Majumdar]

On 21 March 2017 at 15:54, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> When I try to compile following test (see link) in sparse-llvm - LLVM says:
>
> Instruction does not dominate all uses!
>   %load_target = load i32, i32* %191
>   %R122 = icmp eq i32 %load_target4, %load_target
> Instruction does not dominate all uses!
>   %load_target = load i32, i32* %191
>   %R283 = icmp eq i32 %load_target4, %load_target
> Instruction does not dominate all uses!
>   %load_target = load i32, i32* %191
>   %R522 = icmp eq i32 %load_target4, %load_target
>
> I have not yet investigated what the issue is but I thought it best to
> post the test case so that it can be validated.
>
> https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/bugs/cq3.c
>

Appears that the problem is occurring in simplify_one_symbol().

Regards

Re: Another potential issue with linearized output

[Dibyendu Majumdar]

On 21 March 2017 at 21:41, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> On 21 March 2017 at 15:54, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>> When I try to compile following test (see link) in sparse-llvm - LLVM says:
>>
>> Instruction does not dominate all uses!
>>   %load_target = load i32, i32* %191
>>   %R122 = icmp eq i32 %load_target4, %load_target
>> Instruction does not dominate all uses!
>>   %load_target = load i32, i32* %191
>>   %R283 = icmp eq i32 %load_target4, %load_target
>> Instruction does not dominate all uses!
>>   %load_target = load i32, i32* %191
>>   %R522 = icmp eq i32 %load_target4, %load_target
>>
>> I have not yet investigated what the issue is but I thought it best to
>> post the test case so that it can be validated.
>>
>> https://github.com/dibyendumajumdar/dmr_c/blob/master/tests/bugs/cq3.c
>>
>
> Appears that the problem is occurring in simplify_one_symbol().
>

I have tracked this down to the treatment of variable n2 (looking only
at the first function regc() for now).

The C code looks like this:

   for (j=0; j<22; j++)
     switch (s) {
       case 1: if (d[j] != n1) {
                n2 = d[j];
                s = 2;
                nr = 1;
               }
               break;
       case 2: if (d[j] == n1) {
                s = 3;
                break;
               }
               if (d[j] == n2) {
                nr = nr+1;
                break;
               }
               s = 4;
               break;
       case 3: if (d[j] != n1) s = 4;
               break;
     }
   ;

Although there is 1 store and 1 load of n2, the attempt to convert the
load to a pseudo and kill the store seems wrong. Perhaps the
simplification is not taking into account the jumps here due to the
switch? I am not sure how to fix this issue. Ideas?

Thanks and Regards
Dibyendu

Re: Another potential issue with linearized output

[Dibyendu Majumdar]

On 21 March 2017 at 22:21, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> I have tracked this down to the treatment of variable n2.

Here is a small program that reproduces the issue:

static int regc(void)
{
  char r00, r01, r02;
  int s, n1, n2, j, d[2];
  r00 = 0;
  r01 = 1;
  r02 = 2;
  d[0] = &r01 - &r00;
  d[1] = &r02 - &r01;

  n1 = d[0];
  s = 1;

  for (j = 0; j < 2; j++)
    switch (s) {
    case 1:
      n2 = d[j];
      break;
    case 2:
      if (d[j] == n2) {
        break;
      }
      s = 4;
      break;
    };
  return s;
}

Thanks and Regards
Dibyendu

Re: Another potential issue with linearized output

[Luc Van Oostenryck]

On Wed, Mar 22, 2017 at 1:12 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> On 21 March 2017 at 22:21, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>> I have tracked this down to the treatment of variable n2.
>
> Here is a small program that reproduces the issue:
>
> static int regc(void)
> {
>   char r00, r01, r02;
>   int s, n1, n2, j, d[2];
>   r00 = 0;
>   r01 = 1;
>   r02 = 2;
>   d[0] = &r01 - &r00;
>   d[1] = &r02 - &r01;
>
>   n1 = d[0];
>   s = 1;
>
>   for (j = 0; j < 2; j++)
>     switch (s) {
>     case 1:
>       n2 = d[j];
>       break;
>     case 2:
>       if (d[j] == n2) {
>         break;
>       }
>       s = 4;
>       break;
>     };
>   return s;
> }

Interesting case.
It seems that is closely related to the fact that there is some code paths where
n2 is undefined (not yet stored) even if these paths can't happen at execution
time (like j == 0, s == 2).
The memops/symbol simplification then wrongly simplify away the store.

I'll look for a solution.

-- Luc