This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: condition DCE of partially dead calls
Andrew Pinski wrote:
So it was mentioned to me that the reason why for the check is based
on the range of the values rather than based if NaNs and Infs are
supported. So here is a summary of the issues with spu:
TARGET_FLOAT_FORMAT is set to IEEE_FLOAT_FORMAT.
Double is handled the same as IEEE 64bit (except for denorms are
handled as zero IIRC)
float has the same data format as IEEE 32bit but it does not have nans
or infs and has an extended range and denorms are handled as zero.
In GCC, real_format is the struct which has the format of the floating
point representation.
You can get the format for each mode via REAL_MODE_FORMAT.
Yes.
You can get the largest finite value representable in mode by using real_maxval.
Richard mentioned that as well.
Some more comments about the code:
from check_pow:
+ real_from_integer (&mv, VOIDmode, 256, 0, 1);
You really should not being using VOIDmode here but the correct mode
here based on the function call.
Will check (Ian mentioned something similar).
+ if (TREE_CODE (base_var) != VAR_DECL
+ && TREE_CODE (base_var) != PARM_DECL)
Use DECL_P instead.
Ok.
+ bit_sz = TYPE_PRECISION (typ);
+ if (bit_sz > 32)
+ return false;
Huh??? Can you explain why this is needed? Besides exactness but if
we have powf, 32bit integers won't fix exactly into a 32bit float.
Larger sized base value (integer) will make the final shrinkwrapping
condition too conservative (and may not beneficial). WIll add comment.
For gen_one_condition:
+ temp = create_tmp_var (float_typ, temp_name1);
Using a temp name here causes a memory overhead.
Yes.
>And check_builtin_call should be always true for the builtins where
> they are used.
Maybe. I hit assertion with an ppc test case (using -maltivec) --
probably due to the fact I did not check builtin class before
checking builtin function code (but now it is checked).
Thanks,
David
Thanks,
Andrew Pinski