* Potential linearizer over simplication
@ 2017-03-15 0:00 Dibyendu Majumdar
2017-03-16 11:16 ` Dibyendu Majumdar
2017-03-16 17:30 ` Luc Van Oostenryck
0 siblings, 2 replies; 4+ messages in thread
From: Dibyendu Majumdar @ 2017-03-15 0:00 UTC (permalink / raw)
To: Linux-Sparse
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential linearizer over simplication
2017-03-15 0:00 Potential linearizer over simplication Dibyendu Majumdar
@ 2017-03-16 11:16 ` Dibyendu Majumdar
2017-03-16 11:27 ` Dibyendu Majumdar
2017-03-16 17:30 ` Luc Van Oostenryck
1 sibling, 1 reply; 4+ messages in thread
From: Dibyendu Majumdar @ 2017-03-16 11:16 UTC (permalink / raw)
To: Linux-Sparse; +Cc: Luc Van Oostenryck, Christopher Li
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential linearizer over simplication
2017-03-16 11:16 ` Dibyendu Majumdar
@ 2017-03-16 11:27 ` Dibyendu Majumdar
0 siblings, 0 replies; 4+ messages in thread
From: Dibyendu Majumdar @ 2017-03-16 11:27 UTC (permalink / raw)
To: Linux-Sparse; +Cc: Luc Van Oostenryck, Christopher Li
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;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Potential linearizer over simplication
2017-03-15 0:00 Potential linearizer over simplication Dibyendu Majumdar
2017-03-16 11:16 ` Dibyendu Majumdar
@ 2017-03-16 17:30 ` Luc Van Oostenryck
1 sibling, 0 replies; 4+ messages in thread
From: Luc Van Oostenryck @ 2017-03-16 17:30 UTC (permalink / raw)
To: Dibyendu Majumdar; +Cc: Linux-Sparse
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-03-16 17:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-15 0:00 Potential linearizer over simplication Dibyendu Majumdar
2017-03-16 11:16 ` Dibyendu Majumdar
2017-03-16 11:27 ` Dibyendu Majumdar
2017-03-16 17:30 ` Luc Van Oostenryck
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.