On Tue, Oct 25, 2016 at 12:22 PM, Eric Botcazou wrote:
>> I'm not sure what you mean with "all other callers of fits_to_tree_p
>> are affected" - that was desired.
>
> Affected by the from == to eq_p change:
>
> + if (TREE_CODE (type) == BOOLEAN_TYPE)
> +return x == 0 || x == 1;
>
> vs
>
> +
> I'm not sure what you mean with "all other callers of fits_to_tree_p
> are affected" - that was desired.
Affected by the from == to eq_p change:
+ if (TREE_CODE (type) == BOOLEAN_TYPE)
+return x == 0 || x == 1;
vs
+ if (TREE_CODE (type) == BOOLEAN_TYPE)
+return eq_p (x, 0) || eq_p (
On Tue, Oct 25, 2016 at 10:17 AM, Eric Botcazou wrote:
>> Is the change to pass wi::to_widest really necessary? I think it has a
>> runtime penalty.
>
> Yes, because there is no == operator for a (tree, int) pair.
Ah, yes. But operator== simply maps to wi::eq_p, so ...
> Is there a cheap
> wa
> Is the change to pass wi::to_widest really necessary? I think it has a
> runtime penalty.
Yes, because there is no == operator for a (tree, int) pair. Is there a cheap
way to convert a tree back into a wide_int? wi::to_wide? Or a combination
with decompose? Otherwise you can use eq_p, but
On Mon, Oct 24, 2016 at 1:39 PM, Eric Botcazou wrote:
>> > But integer_truep is just integer_onep for BOOLEAN_TYPEs.
>>
>> Yes, but it's more descriptive IMHO.
>
> At the cost of consistency with fits_to_tree_p though.
>
>> fits_to_tree_p avoids creating an INTEGER_CST in ggc memory and thus is th
> > But integer_truep is just integer_onep for BOOLEAN_TYPEs.
>
> Yes, but it's more descriptive IMHO.
At the cost of consistency with fits_to_tree_p though.
> fits_to_tree_p avoids creating an INTEGER_CST in ggc memory and thus is the
> prefered way to test if you have a wide-int but not yet an
On Mon, Oct 24, 2016 at 11:15 AM, Eric Botcazou wrote:
>> Btw, if int_fits_type_p is supposed to be only called for INTEGER_TYPEs
>> then
>>
>> /* If arg1 is an INTEGER_CST, fold it to new type. */
>> if (INTEGRAL_TYPE_P (TREE_TYPE (new_arg0))
>> && int_fits_type_p (arg1, TR
> Btw, if int_fits_type_p is supposed to be only called for INTEGER_TYPEs
> then
>
> /* If arg1 is an INTEGER_CST, fold it to new type. */
> if (INTEGRAL_TYPE_P (TREE_TYPE (new_arg0))
> && int_fits_type_p (arg1, TREE_TYPE (new_arg0)))
> {
> if (gimple_assig
On Fri, Oct 21, 2016 at 9:40 AM, Eric Botcazou wrote:
>> Btw, isn't this the issue? You'd need to avoid this as well I guess:
>>
>> /* Special case comparing booleans against a constant as we
>> know the value of OP0 on both arms of the branch. i.e., we
>> can
> Btw, isn't this the issue? You'd need to avoid this as well I guess:
>
> /* Special case comparing booleans against a constant as we
> know the value of OP0 on both arms of the branch. i.e., we
> can record an equivalence for OP0 rather than COND.
>
>
> Because boolean_type_node was different? Well, are really _all_ boolean
> types this way or can you keep using BOOLEAN_TYPE for boolean_type_node for
> things like interfacing to C and C++ (and the builtins, etc.) and use
> ENUMERAL_TYPE for the cases where bool can have non zero/one values?
Th
On Tue, Oct 18, 2016 at 8:35 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on the mainline and 6 branch: the compiler now
> generates wrong code for the attached testcase at -O because of an internal
> conflict about boolean types. The sequence is as follows. In .mergephi3:
>
>
On Thu, Oct 20, 2016 at 12:50 AM, Eric Botcazou wrote:
>> Because BOOLEAN_TYPE types only have two values as documented in
>> tree.def:
>>
>> /* Boolean type (true or false are the only values). Looks like an
>>INTEGRAL_TYPE. */
>> DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0)
>
>
> Because BOOLEAN_TYPE types only have two values as documented in
> tree.def:
>
> /* Boolean type (true or false are the only values). Looks like an
>INTEGRAL_TYPE. */
> DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0)
Yes, but on the other hand they have a precision and a range.
>
On Tue, Oct 18, 2016 at 4:10 PM, Jeff Law wrote:
> On 10/18/2016 02:35 AM, Richard Biener wrote:
>>
>> On Tue, Oct 18, 2016 at 8:35 AM, Eric Botcazou
>> wrote:
>>>
>>> Hi,
>>>
>>> this is a regression present on the mainline and 6 branch: the compiler
>>> now
>>> generates wrong code for the atta
On 10/18/2016 02:35 AM, Richard Biener wrote:
On Tue, Oct 18, 2016 at 8:35 AM, Eric Botcazou wrote:
Hi,
this is a regression present on the mainline and 6 branch: the compiler now
generates wrong code for the attached testcase at -O because of an internal
conflict about boolean types. The seq
On Tue, Oct 18, 2016 at 8:35 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on the mainline and 6 branch: the compiler now
> generates wrong code for the attached testcase at -O because of an internal
> conflict about boolean types. The sequence is as follows. In .mergephi3:
>
>
17 matches
Mail list logo
