Richi,
I also think that it is a digression to have this discussion about
rtl.The root problem is really that Mike, Richard, and myself do not
believe that infinite precision math is the proper way to do math for
the majority of the compiler. Most of the compiler, at both the rtl
and tr
On 05/03/2013 09:02 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:45 PM, Kenneth Zadeck wrote:
On 05/03/2013 07:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
On 04/
On 05/03/2013 08:53 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:37 PM, Richard Sandiford
wrote:
Richard Biener writes:
See e.g. the hoops that cselib has to jump through:
/* We need to pass down the mode of constants through the hash table
functions. For that purpose, wrap them i
On 05/03/2013 08:40 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 2:31 PM, Kenneth Zadeck wrote:
On 05/03/2013 08:12 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck
wrote:
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zade
Richard Biener writes:
>> But storing the mode in the rtx is orthogonal to what Kenny is doing.
>> The mode of each rtx constant is already available in the places
>> that Kenny is changing, because we already do the work to keep track
>> of the mode separately. Being able to get the mode directl
Richard Biener writes:
>> 5) All const_ints in the .md files would need to be given a mode
>>(except for those places where const_int actually represents
>>a C++ constant, such as in attributes).
>>
>> I realise your list wasn't supposed to be exhaustive, and neither's mine :-)
>
> Now, do
On Fri, May 3, 2013 at 2:48 PM, Richard Sandiford
wrote:
> Kenneth Zadeck writes:
>> There are several problems with just dropping a mode into the already
>> existing mode field of an rtx constant.
>> 1) There may be places where the a back end is testing equality to see
>> if constants of differ
On Fri, May 3, 2013 at 2:45 PM, Kenneth Zadeck wrote:
> On 05/03/2013 07:19 AM, Richard Biener wrote:
>>
>> On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
>
> On 04/24/2013
On Fri, May 3, 2013 at 2:37 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>>> See e.g. the hoops that cselib has to jump through:
>>>
>>> /* We need to pass down the mode of constants through the hash table
>>>functions. For that purpose, wrap them in a CONST of the appropriate
>>>
Kenneth Zadeck writes:
> There are several problems with just dropping a mode into the already
> existing mode field of an rtx constant.
> 1) There may be places where the a back end is testing equality to see
> if constants of different modes are in fact the same value.
> 2) Most of the places
On 05/03/2013 07:19 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
On 04/24/2013 09:36 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
Ri
On Fri, May 3, 2013 at 2:31 PM, Kenneth Zadeck wrote:
> On 05/03/2013 08:12 AM, Richard Biener wrote:
>>
>> On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck
>> wrote:
>>>
>>> On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
>
>
Richard Biener writes:
>> See e.g. the hoops that cselib has to jump through:
>>
>> /* We need to pass down the mode of constants through the hash table
>>functions. For that purpose, wrap them in a CONST of the appropriate
>>mode. */
>> static rtx
>> wrap_constant (enum machine_mode mod
On 05/03/2013 08:12 AM, Richard Biener wrote:
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck wrote:
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard San
On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck wrote:
> On 05/03/2013 07:34 AM, Richard Biener wrote:
>>
>> On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
>> wrote:
>>>
>>> On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
>>
On 05/03/2013 07:34 AM, Richard Biener wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
wrote:
> On 04/24/2013 11:13 AM, Richard Biener wrote:
>>
>> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
>
> In othe
On Wed, Apr 24, 2013 at 5:55 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
> In other words, one of the reasons wide_int ca
On Wed, Apr 24, 2013 at 5:29 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
>> wrote:
>>> On 04/24/2013 09:36 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
>
> Richard Biener
On 04/24/2013 11:13 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
Richard Biener writes:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
In other words, one of the reasons wide_int can't be exactly 1:1
in practice is because it is clearing o
Richard Biener writes:
> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
>>> wrote:
In other words, one of the reasons wide_int can't be exactly 1:1
in practice is because it is clearing out t
Richard Biener writes:
> On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
> wrote:
>> On 04/24/2013 09:36 AM, Richard Biener wrote:
>>>
>>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
>
> Can we in such cases please to a preparatory patc
On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
>> wrote:
>>> In other words, one of the reasons wide_int can't be exactly 1:1
>>> in practice is because it is clearing out these mistakes (GEN_INT
>>> rather
On Wed, Apr 24, 2013 at 4:35 PM, Kenneth Zadeck
wrote:
> On 04/24/2013 09:36 AM, Richard Biener wrote:
>>
>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>> wrote:
>>>
>>> Richard Biener writes:
Can we in such cases please to a preparatory patch and change the
CONST_INT/CONS
Richard Biener writes:
> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
> wrote:
>> In other words, one of the reasons wide_int can't be exactly 1:1
>> in practice is because it is clearing out these mistakes (GEN_INT
>> rather than gen_int_mode) and missing features (non-power-of-2 widths).
On 04/24/2013 10:42 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
Richard Biener writes:
I suppose the above should use immed_double_int_const (v, mode), too,
In practice it doesn't matter, because...
which oddly only ever truncates to mode for modes <
On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> I suppose the above should use immed_double_int_const (v, mode), too,
>
> In practice it doesn't matter, because...
>
>> which oddly only ever truncates to mode for modes <= HOST_BITS_PER_WIDE_INT
>> via gen_int
On 04/24/2013 09:36 AM, Richard Biener wrote:
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
Richard Biener writes:
Can we in such cases please to a preparatory patch and change the
CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
mode precision first?
I'm not sure what y
Richard Biener writes:
> I suppose the above should use immed_double_int_const (v, mode), too,
In practice it doesn't matter, because...
> which oddly only ever truncates to mode for modes <= HOST_BITS_PER_WIDE_INT
> via gen_int_mode.
...right. That's because there's not really any proper supp
On Wed, Apr 24, 2013 at 4:03 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
Can we in such cases please to a preparatory patch and change the
CONST_INT/CONST_DOUBLE paths to do an explici
Richard Biener writes:
> On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> Can we in such cases please to a preparatory patch and change the
>>> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
>>> mode precision first?
>>
>> I'm not sure what you
On Wed, Apr 24, 2013 at 2:44 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> Can we in such cases please to a preparatory patch and change the
>> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
>> mode precision first?
>
> I'm not sure what you mean here. CONST_INT HWIs are al
Richard Biener writes:
> Can we in such cases please to a preparatory patch and change the
> CONST_INT/CONST_DOUBLE paths to do an explicit [sz]ext to
> mode precision first?
I'm not sure what you mean here. CONST_INT HWIs are already sign-extended
from mode precision to HWI precision. The 8-bi
On Tue, Apr 16, 2013 at 10:17 PM, Kenneth Zadeck
wrote:
> Here is a refreshed version of the rtl changes for wide-int. the only
> change from the previous versions is that the wide-int binary operations
> have been simplified to use the new wide-int binary templates.
Looking for from_rtx calls
34 matches
Mail list logo
