Re: HiPe compiler FP inlining crashing
Björn-Egil Dahlberg <[email protected]> Wed, 25 Nov 2015 23:08:16 +0100
| Newsgroups | gmane.comp.lang.erlang.bugs |
|---|---|
| Message-ID | <CAMjYFoNmTUhkD2EoF1wOiFounVmzh3gtWwf9FSA2Ub2ON-vcNQ@mail.gmail.com> |
--===============6353901528754614346==
Content-Type: multipart/alternative; boundary=001a113fbbec0274cd052564b28f
--001a113fbbec0274cd052564b28f
Content-Type: text/plain; charset=UTF-8
snarky ..
Before anyone goes on a wild-goose chase, there exists another sample code,
without maps, that also crashes the HiPE compiler on,
- 18.1
- 17.5.6
- OTP_R16B03-1
- OTP_R15B03-1
- stopped testing here .. perhaps the bug is in the original implementation
..
f(A, C, D, E, L) ->
lists:foldl(fun (X, P) ->
AVar = case A of
0 -> 1 / D;
N -> N / C
end,
BVar = case E of
atom1 -> 1.0;
atom2 -> 0.8;
_ -> E
end,
CVar = case X of
atom1 -> 0.1 * AVar;
_ -> 1.0
end,
P * BVar * CVar
end, 1, L).
Not necessarily the same bug as above but it has the same symptoms, i.e.
function clause on hipe_icode_fp assert_assigned and no_inline_fp compiles
fine.
2015-11-25 22:20 GMT+01:00 Kostis Sagonas <[email protected]>:
> On 11/25/2015 08:46 PM, Mikael Pettersson wrote:
>
>> > The code compiles without problem if running the compiler without the
>> +native flag. With the flag, the compiler will crash.
>> > If compiling with the no_inline_fp flag enabled, the compiler does
>> not crash.
>>
>> I can reproduce the compiler crash with OTP 18.1 on Linux/x86_64, but not
>> with OTP 17.5.
>> The crash is in a sanity check (hipe_icode_fp:assert_assigned/1) at the
>> ICode level, well
>> before any target-dependent code is generated.
>>
>> This could be caused by changes in the BEAM compiler's output, or by some
>> change in HiPE.
>> Presumably a git bisect ought to identify it; care to try that?
>>
>
> I've also looked at this one this afternoon. I am willing to bet this is
> related to the presence of maps in the code -- most likely due to their
> "better" compilation by BEAM in 18.x.
>
> Given that the code that propagates floating point values in ICode was
> written back in 2003 or so and practically not much changed since then,
> it's not surprising that this code breaks as new types and instructions are
> introduced to the BEAM compiler.
>
> I'll try to find some time to look into this, but would not mind if
> somebody else beats me to it.
>
> Kostis
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> [email protected]
> http://erlang.org/mailman/listinfo/erlang-bugs
>
--001a113fbbec0274cd052564b28f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">snarky ..<div><br></div><div>Before anyone goes on a wild-=
goose chase, there exists another sample code, without maps, that also cras=
hes the HiPE compiler on,</div><div>- 18.1</div><div>- 17.5.6</div><div>- O=
TP_R16B03-1</div><div>- OTP_R15B03-1</div><div>- stopped testing here .. pe=
rhaps the bug is in the original implementation ..</div><div><br></div><fon=
t face=3D"monospace, monospace">f(A, C, D, E, L) -><br>=C2=A0 =C2=A0 lis=
ts:foldl(fun (X, P) -><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AVar =3D case A of<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 -> 1 / D;<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N -> N / C<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0end,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BVar =3D case E of<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0atom1 -> 1.0;<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0atom2 -> 0.8;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0_ -> E<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0en=
d,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 CVar =3D case X of<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0atom1 -> 0.1 * AVar;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0_ -> 1.0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end,<b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 P * BVar * CVar<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 end, 1, L).</font><div><br></div><div>Not necessarily the same b=
ug as above but it has the same symptoms, i.e. function clause on hipe_icod=
e_fp assert_assigned and no_inline_fp compiles fine.</div><div><br></div><d=
iv><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">2015-11-25 22:20 GMT+01:00 Kostis Sagonas <span dir=3D"ltr"><<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>></=
span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 11/25/2015 08:=
46 PM, Mikael Pettersson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 > The code compiles without problem if running the compiler witho=
ut the +native flag. With the flag, the compiler will crash.<br>
=C2=A0 > If compiling with the no_inline_fp flag enabled, the compiler d=
oes not crash.<br>
<br>
I can reproduce the compiler crash with OTP 18.1 on Linux/x86_64, but not w=
ith OTP 17.5.<br>
The crash is in a sanity check (hipe_icode_fp:assert_assigned/1) at the ICo=
de level, well<br>
before any target-dependent code is generated.<br>
<br>
This could be caused by changes in the BEAM compiler's output, or by so=
me change in HiPE.<br>
Presumably a git bisect ought to identify it; care to try that?<br>
</blockquote>
<br></span>
I've also looked at this one this afternoon.=C2=A0 I am willing to bet =
this is related to the presence of maps in the code -- most likely due to t=
heir "better" compilation by BEAM in 18.x.<br>
<br>
Given that the code that propagates floating point values in ICode was writ=
ten back in 2003 or so and practically not much changed since then, it'=
s not surprising that this code breaks as new types and instructions are in=
troduced to the BEAM compiler.<br>
<br>
I'll try to find some time to look into this, but would not mind if som=
ebody else beats me to it.<span class=3D"HOEnZb"><font color=3D"#888888"><b=
r>
<br>
Kostis</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
erlang-bugs mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">erlang-bugs@erl=
ang.org</a><br>
<a href=3D"http://erlang.org/mailman/listinfo/erlang-bugs" rel=3D"noreferre=
r" target=3D"_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
</div></div></blockquote></div><br></div>
--001a113fbbec0274cd052564b28f--
--===============6353901528754614346==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs
--===============6353901528754614346==--