On November 16, 2014 1:07:59 PM CET, Marc Glisse <marc.gli...@inria.fr> wrote:
>Hello,
>
>this patch breaks gcc.dg/torture/pr50396.c, and I believe this is a
>symptom of a bigger issue: the HONOR_NANS interface is bad (or at least
>
>the way we are using it is bad). To know if a type honors NaN, we first
>
>get its TYPE_MODE and then call HONOR_NANS on that. But for vectors
>that
>do not directly map to hardware, the mode is BLKmode, for which
>HONOR_NANS
>returns false (bad luck, the default is unsafe).
>
>We could introduce a function:
>
>bool
>honor_nans (machine_mode m)
>{
> // check for BLKmode?
> return HONOR_NANS (m);
>}
>bool
>honor_nans (const_tree t)
>{
> if (!TYPE_P (t))
> t = TREE_TYPE (t);
> if (VECTOR_TYPE_P (t) || COMPLEX_TYPE_P (t))
> t = TREE_TYPE (t);
> return honor_nans (TYPE_MODE (t));
>}
>
>and use it in many places. Or call it honors_nan so we don't have to
>rename variables. Or maybe a function ignore_nans instead, that returns
>
>!honor_nans. I am hoping that the element type of a vector always has a
>
>mode, otherwise the function will need to be a bit more complicated.
>
>But the same issue also affects HONOR_SIGNED_ZEROS, HONOR_SNANS,
>HONOR_INFINITIES, etc. It is going to be a pain to add a new function
>for
>each and replace uses. We could instead replace those calls to
>TYPE_MODE
>by a new:
>
>machine_mode
>element_mode (const_tree t)
>{
> if (!TYPE_P (t))
> t = TREE_TYPE (t);
> if (VECTOR_TYPE_P (t) || COMPLEX_TYPE_P (t))
> t = TREE_TYPE (t);
> return TYPE_MODE (t);
>}
>
>so we still have to use HONOR_NANS on the result but at least we only
>introduce one new function.
>
>Any opinion on how best to handle that? I can't promise I'll have time
>to
>work on it any time soon (I might, but I don't know).
I think the element_mode is the way to go.
Eventually implicitly by introducing honor_Nan's (type) which would also reduce
typing.
Richard.
