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.
Thanks and Regards
Dibyendu
--
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
