On 6/5/25 11:00, Jakub Jelinek wrote:
Hi!
The following patch adds support for float <-> integer conversions in
ranger.
The patch reverts part of the r16-571 changes, those changes were right
for fold_range, but not for op1_range, where RO_IFI and RO_FIF are actually
called rather than RO_IFF and RO_FII that the patch expected.
Yeah, the "unused" parameter becomes a bit confusing for op1_range and
op2_range.. I may have actually put them in wrong :-P The 2rd
parameter is suppose to be the same as the "unknown" we are solving
for... but in the case of op1_range and op2_range I don't think we
ever use them? as long as the routines being created match the pattern
of what is invoked, maybe its a moot point.. sorry if I got that wrong.
Also, the float -> int operation actually uses FIX_TRUNC_EXPR tree code
rather than NOP_EXPR or CONVERT_EXPR and int -> float uses FLOAT_EXPR,
but I think we can just handle all of them using operator_cast, at least
as long as we don't try to use VIEW_CONVERT_EXPR using that too; not really
sure handling VCE at least for floating to integral or vice versa would
be actually useful though.
The patch "regressed" two tests, gfortran.dg/inline_matmul_16.f90 and
g++.dg/tree-ssa/loop-split-1.C. In the first case, there is a loop doing
matmul on various sizes of matrices, up to 10x10 matrices, and Fortran
FE given the options emits two implementations of the matmul, one inline
for the case where the matmul has less than 1000 elements and one for
larger matmuls. The check for whatever reason uses floating point
calculations and before this patch we weren't able to prove that all the
matrices will be smaller than the cutoff and the test was checking for
presence of the fallback call; with the patch we are able to figure it
out and only keep the inline copy. I've duplicated the test, once
unmodified source which doesn't expect _gfortran_matmul string in optimized
dump anymore, and another copy which uses volatile ten instead of 10 in
loop upper bounds so that it has to keep the fallback and scans for it.
The other test is g++.dg/tree-ssa/loop-split-1.C, which does
constexpr unsigned s = 100000000;
...
for(unsigned i = 0; i < s; ++i)
{
if(i == 0)
a[i] = b[i] * c[i];
else
a[i] = (b[i] + c[i]) * c[i-1] * std::log(i);
}
and for some reason the successful loop splitting for which the test
searches in a dump file is dependent on the errno fallback of std::log,
where we do t = std::log((double)i); if ((double)i) u> 0); else log ((double)i);
But i goes only from 1 to 100000000, so (double)i has the range
[1.0, 100000000.0] with the patch and so we see it will never need errno
nor raise exception. I've tested adding + d for it where d is 0.0 but
modifiable in some other TU, and tested it also with r14-2851 and r14-2852,
where the former FAILed the test both unmodified and modified, while
the latter PASSed both versions.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK by me.
Andrew
