Can gatekeeper help review this patch? This is a bug in cflow optimization exposed when a cmpi32 is changed to cmpi8
int main()
{
long long ll = 0x7EF0LL;
unsigned char c = (char) ll;
if (c != 0xf0)
return 1;
return 0;
}
opencc -O0, run result's value is 0.
opencc -O1, run result's value is 1.
This is a problem in O2 or higher is because wopt handle remove this branch.
without mov-ext in EBO, cflow can't optimize convert the if branch into goto
opencc -O1 -CG:movext_icmp=off
[ 2, 0] GTN4(%rsp) :- spadjust GTN4(%rsp)<defopnd> (0x0) ;
[ 3, 0] TN149 :- ldc64 (0x7ef0) ;
[ 3, 0] :- store64 TN149 GTN4(%rsp) (sym:ll+0) ;
[ 4, 0] :- store8 TN149 GTN4(%rsp) (sym:c+0) ;
[ 0, 0] TN152 :- movzbl TN149 ;
[ 5, 0] TN33(%rflags) :- cmpi32 TN152 (0xf0) ;
[ 5, 0] :- je TN33(%rflags) (lab:.L_0_770) ;
when turn on movext_icmp
[ 3, 0] TN149 :- ldc64 (0x7ef0) ;
[ 3, 0] :- store64 TN149 GTN4(%rsp) (sym:ll+0) ;
[ 4, 0] :- store8 TN149 GTN4(%rsp) (sym:c+0) ;
[ 5, 0] TN33(%rflags) :- cmpi8 TN149 (0xf0) ;
[ 5, 0] :- je TN33(%rflags) (lab:.L_0_770) ;
it get TN149's value is 0x7ef0, then directly compare with 0xf0 without
truncate.
There is original a function Extend_Short_Cmp_Src, truncate and sign extend
short sign value for compare constant.
The fix is truncate the constant to one bytes or two bytes if compare is
short unsigned compare.
cflow.patch
Description: Binary data
------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
