On 16 March 2017 at 11:16, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote:
> On 15 March 2017 at 00:00, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> 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;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
