On 03/16/2012 09:49 PM, Richard Henderson wrote:
> On 03/16/12 05:36, Bernd Schmidt wrote:
>> The machine is "special". Pointer addition is a different operation than
>> integer addition. It'll also need a new ptr_plus rtx code which takes a
>> Pmode and an SImode operand. Pmode is larger than SImo
On 03/16/12 05:36, Bernd Schmidt wrote:
> The machine is "special". Pointer addition is a different operation than
> integer addition. It'll also need a new ptr_plus rtx code which takes a
> Pmode and an SImode operand. Pmode is larger than SImode but fits in a
> single register; intptr_t (which is
On Fri, Mar 16, 2012 at 4:49 PM, Zdenek Dvorak wrote:
> Hello,
>
>> On 03/16/2012 02:46 PM, Richard Guenther wrote:
>> > In the end what we want is a POINTER_PLUS_EXPR variant
>> > that does not make alias-analysis assume the result still points
>> > to within the objects the pointer pointed to be
Hello,
> On 03/16/2012 02:46 PM, Richard Guenther wrote:
> > In the end what we want is a POINTER_PLUS_EXPR variant
> > that does not make alias-analysis assume the result still points
> > to within the objects the pointer pointed to before the increment/decrement.
>
> Hold on, is alias analysis
On 03/16/2012 02:46 PM, Richard Guenther wrote:
> In the end what we want is a POINTER_PLUS_EXPR variant
> that does not make alias-analysis assume the result still points
> to within the objects the pointer pointed to before the increment/decrement.
Hold on, is alias analysis really affected by t
On 03/16/2012 02:46 PM, Richard Guenther wrote:
> We do have three pointer offsetting operations at the moment,
> POINTER_PLUS_EXPR, &MEM_REF and &TARGET_MEM_REF.
> All of which expect C pointer semantics (if they can see the base
> pointer, which is why I suggested to create a TARGET_MEM_REF
> wit
On Fri, Mar 16, 2012 at 2:37 PM, Bernd Schmidt wrote:
> On 03/16/2012 02:33 PM, Zdenek Dvorak wrote:
> Yes, that could work. ?Though it might end up being incredibly ugly ;)
In the code? Should really only change a few lines in the patch I would
have thought. I'll get back to yo
On 03/16/2012 02:33 PM, Zdenek Dvorak wrote:
Yes, that could work. ?Though it might end up being incredibly ugly ;)
>>>
>>> In the code? Should really only change a few lines in the patch I would
>>> have thought. I'll get back to you when I have a new version - thanks
>>> for the tip.
>>
>> N
> >> Yes, that could work. ?Though it might end up being incredibly ugly ;)
> >
> > In the code? Should really only change a few lines in the patch I would
> > have thought. I'll get back to you when I have a new version - thanks
> > for the tip.
>
> No, in the GIMPLE IL.
>
> Richard.
And I can
On Fri, Mar 16, 2012 at 2:18 PM, Bernd Schmidt wrote:
> On 03/16/2012 02:15 PM, Richard Guenther wrote:
>> Hmm, ok. So to have your lea represented on RTL you cannot use
>> a fancy pattern using add because it would not be an add. Hmm.
>> If it merely does not affect upper bits then
>>
>> (set
On 03/16/2012 02:15 PM, Richard Guenther wrote:
> Hmm, ok. So to have your lea represented on RTL you cannot use
> a fancy pattern using add because it would not be an add. Hmm.
> If it merely does not affect upper bits then
>
> (set (reg:SI ptr) (add (reg:SI ptr) (reg:SI off))
>
> might work
On Fri, Mar 16, 2012 at 2:05 PM, Bernd Schmidt wrote:
> On 03/16/2012 01:55 PM, Richard Guenther wrote:
>> On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt
>> wrote:
>>>
>>> The machine is "special". Pointer addition is a different operation than
>>> integer addition. It'll also need a new ptr_plu
On 03/16/2012 01:55 PM, Richard Guenther wrote:
> On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt
> wrote:
>>
>> The machine is "special". Pointer addition is a different operation than
>> integer addition. It'll also need a new ptr_plus rtx code which takes a
>> Pmode and an SImode operand. Pmode
On Fri, Mar 16, 2012 at 1:36 PM, Bernd Schmidt wrote:
> On 03/16/2012 11:08 AM, Richard Guenther wrote:
>>
>> Your patch as-is is not safe at the moment. But why is casting a pointer
>> to an integer prohibitly expensive? That fact should be an implementation
>> detail of GIMPLE. Or is it the i
On 03/16/2012 11:08 AM, Richard Guenther wrote:
>
> Your patch as-is is not safe at the moment. But why is casting a pointer
> to an integer prohibitly expensive? That fact should be an implementation
> detail of GIMPLE. Or is it the issue that IVOPTs chooses an integer
> type that does not nec
On Fri, Mar 16, 2012 at 1:13 AM, Andrew Pinski wrote:
> On Thu, Mar 15, 2012 at 5:09 PM, Bernd Schmidt
> wrote:
>> On 03/16/2012 12:44 AM, Jakub Jelinek wrote:
>>> For pointer arithmetics in the IL we assume the C
>>> requirements, pointer arithmetics can be performed only within the same
>>> ob
On Thu, Mar 15, 2012 at 5:09 PM, Bernd Schmidt wrote:
> On 03/16/2012 12:44 AM, Jakub Jelinek wrote:
>> For pointer arithmetics in the IL we assume the C
>> requirements, pointer arithmetics can be performed only within the same
>> object, so for
>> int a[10];
>> both of the following are invalid,
On 03/16/2012 12:44 AM, Jakub Jelinek wrote:
> For pointer arithmetics in the IL we assume the C
> requirements, pointer arithmetics can be performed only within the same
> object, so for
> int a[10];
> both of the following are invalid, even in the IL:
> int *p = a - 1;
> int *q = a + 11;
Ok, so
Hi,
> > Well, what are our rules for whether overflow on POINTER_PLUS_EXPR is
> > defined or not? A quick search through the headers and docs doesn't turn
> > up anything. Would there be a downside to defining it as wrapping?
> >
> > Can you show an example where a POINTER_PLUS_EXPR produced by i
On Fri, Mar 16, 2012 at 12:20:44AM +0100, Bernd Schmidt wrote:
> On 03/16/2012 12:16 AM, Jakub Jelinek wrote:
> > On Fri, Mar 16, 2012 at 12:03:08AM +0100, Bernd Schmidt wrote:
> >> On 03/15/2012 11:12 PM, Zdenek Dvorak wrote:
> >>
> >>> the reason unsigned integer types are prefered is that possib
On 03/16/2012 12:16 AM, Jakub Jelinek wrote:
> On Fri, Mar 16, 2012 at 12:03:08AM +0100, Bernd Schmidt wrote:
>> On 03/15/2012 11:12 PM, Zdenek Dvorak wrote:
>>
>>> the reason unsigned integer types are prefered is that possible overflows
>>> during the computation have defined semantics. With poi
On Fri, Mar 16, 2012 at 12:03:08AM +0100, Bernd Schmidt wrote:
> On 03/15/2012 11:12 PM, Zdenek Dvorak wrote:
>
> > the reason unsigned integer types are prefered is that possible overflows
> > during the computation have defined semantics. With pointer types, the
> > intermediate steps of the co
On 03/15/2012 11:12 PM, Zdenek Dvorak wrote:
> the reason unsigned integer types are prefered is that possible overflows
> during the computation have defined semantics. With pointer types, the
> intermediate steps of the computations could have undefined behavior, possibly
> confusing further op
Hi,
> Currently, tree-ssa-loop-ivopts assumes that pointers and integers can
> be used interchangeably. It prefers to compute everything in unsigned
> integer types rather than pointer types.
> On a new target that I'm working on, this assumption is problematic;
> casting a pointer to an integer a
24 matches
Mail list logo
