Hi Richard,
I have a patch for PR43814. It introduces an option that assumes that function
arguments of pointer type are aligned, and uses that information in
tree-ssa-ccp. This enables the memcpy in pr43814-2.c to be inlined.
I tested the patch successfully on-by-default on x86_64 and i686 (both
Hi Tom
What's the behavior of your patch to the following case
typedef int int_unaligned __attribute__((aligned(1)));
int foo (int_unaligned *p)
{
return *p;
}
thanks
Carrot
On Tue, Sep 20, 2011 at 7:13 PM, Tom de Vries wrote:
> Hi Richard,
>
> I have a patch for PR43814. It introduces an op
On 09/28/2011 03:57 PM, Carrot Wei wrote:
> Hi Tom
>
> What's the behavior of your patch to the following case
>
> typedef int int_unaligned __attribute__((aligned(1)));
> int foo (int_unaligned *p)
> {
> return *p;
> }
>
I modified the example slightly:
test.c:
...
typedef int __attribute__
On 24/09/2011, at 9:40 PM, Jakub Jelinek wrote:
> On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
>> In the end I'd probably say the patch is ok without the option (thus
>> turned on by default), but if LC_GLOBAL_LOCALE is part of the
>> glibc ABI then we clearly can't do this.
>
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:29:12 +1300
> GLIBC patch to fix locale_t definition is attached.
Isn't this going to result in byte loads being used to dereference
all locale_t pointers on targets like sparc and mips?
On 29/09/2011, at 7:35 AM, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:29:12 +1300
>
>> GLIBC patch to fix locale_t definition is attached.
>
> Isn't this going to result in byte loads being used to dereference
> all locale_t pointers on targets like sparc and mips?
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:40:55 +1300
> On 29/09/2011, at 7:35 AM, David Miller wrote:
>
>> From: Maxim Kuvyrkov
>> Date: Thu, 29 Sep 2011 07:29:12 +1300
>>
>>> GLIBC patch to fix locale_t definition is attached.
>>
>> Isn't this going to result in byte loads being used t
On 29/09/2011, at 7:41 AM, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:40:55 +1300
>
>> On 29/09/2011, at 7:35 AM, David Miller wrote:
>>
>>> From: Maxim Kuvyrkov
>>> Date: Thu, 29 Sep 2011 07:29:12 +1300
>>>
GLIBC patch to fix locale_t definition is attached.
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:45:17 +1300
> OK. Do you have an alternative suggestion that would fix non-portable use of
> locale_t?
Don't optimize something that is invalidated by a quite common practice?
What about people who encode invalid pointers with "0xdeadbeef", do we
David,
To summarize, your opinion seems to be to not enable the optimization by
default, correct?
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
On 29/09/2011, at 7:48 AM, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:45:17 +1300
>
>> OK. Do you have
From: Maxim Kuvyrkov
Date: Thu, 29 Sep 2011 07:58:01 +1300
> To summarize, your opinion seems to be to not enable the
> optimization by default, correct?
Yes, and I don't think we ever could do so.
BTW, another common paradigm is using the "always clear" bits of a
pointer to encode state bits.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/28/11 13:00, David Miller wrote:
> From: Maxim Kuvyrkov Date: Thu, 29 Sep
> 2011 07:58:01 +1300
>
>> To summarize, your opinion seems to be to not enable the
>> optimization by default, correct?
>
> Yes, and I don't think we ever could do so.
On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
> From: Maxim Kuvyrkov
> Date: Thu, 29 Sep 2011 07:58:01 +1300
>
> > To summarize, your opinion seems to be to not enable the
> > optimization by default, correct?
>
> Yes, and I don't think we ever could do so.
>
> BTW, another comm
On Wed, Sep 28, 2011 at 9:13 PM, Jakub Jelinek wrote:
> On Wed, Sep 28, 2011 at 03:00:09PM -0400, David Miller wrote:
>> From: Maxim Kuvyrkov
>> Date: Thu, 29 Sep 2011 07:58:01 +1300
>>
>> > To summarize, your opinion seems to be to not enable the
>> > optimization by default, correct?
>>
>> Yes,
On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
> There is nothing like "very likely aligned" ;) Note that what is new is
On non-strict aligned targets there is no reason not to have something like
"very likely aligned". You would expand stores/loads as if it was aligned
in tha
On Sep 20, 2011, at 4:13 AM, Tom de Vries wrote:
> I have a patch for PR43814. It introduces an option that assumes that function
> arguments of pointer type are aligned, and uses that information in
> tree-ssa-ccp. This enables the memcpy in pr43814-2.c to be inlined.
I'm not a huge fan of an opt
On 09/24/2011 11:31 AM, Richard Guenther wrote:
> On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries wrote:
>> Hi Richard,
>>
>> I have a patch for PR43814. It introduces an option that assumes that
>> function
>> arguments of pointer type are aligned, and uses that information in
>> tree-ssa-ccp. Thi
From: Mike Stump
Date: Wed, 28 Sep 2011 15:19:10 -0700
> If Android is safe in this respect, then, they can just turn it on,
> and then force anyone porting software to their platform to `fix'
> their code.
They'd have to then know to turn this option off when building the kernel,
which does use
On Wed, Sep 28, 2011 at 06:43:04PM -0400, David Miller wrote:
> From: Mike Stump
> Date: Wed, 28 Sep 2011 15:19:10 -0700
>
> > If Android is safe in this respect, then, they can just turn it on,
> > and then force anyone porting software to their platform to `fix'
> > their code.
>
> They'd have
On 09/29/2011 12:21 AM, Tom de Vries wrote:
> On 09/24/2011 11:31 AM, Richard Guenther wrote:
>> On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries wrote:
>>> Hi Richard,
>>>
>>> I have a patch for PR43814. It introduces an option that assumes that
>>> function
>>> arguments of pointer type are aligne
On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek wrote:
> On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
>> There is nothing like "very likely aligned" ;) Note that what is new is
>
> On non-strict aligned targets there is no reason not to have something like
> "very likely alig
On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
> On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek wrote:
> > On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
> >> There is nothing like "very likely aligned" ;) Note that what is new is
> >
> > On non-strict align
On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries wrote:
> On 09/29/2011 12:21 AM, Tom de Vries wrote:
>> On 09/24/2011 11:31 AM, Richard Guenther wrote:
>>> On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries
>>> wrote:
Hi Richard,
I have a patch for PR43814. It introduces an option that
On Thu, Sep 29, 2011 at 11:20 AM, Jakub Jelinek wrote:
> On Thu, Sep 29, 2011 at 11:11:12AM +0200, Richard Guenther wrote:
>> On Wed, Sep 28, 2011 at 10:08 PM, Jakub Jelinek wrote:
>> > On Wed, Sep 28, 2011 at 09:56:27PM +0200, Richard Guenther wrote:
>> >> There is nothing like "very likely alig
On 09/29/11 11:26, Richard Guenther wrote:
> Maybe that was the PR the patch is about, but surely we can't treat
> a memcpy (p, ..) like *p. Which means we'd use the declared type
> of p only. And we can do so only for parameters (intermediate conversions
> are dropped), which would make the case
On Thu, Sep 29, 2011 at 12:51 PM, Bernd Schmidt wrote:
> On 09/29/11 11:26, Richard Guenther wrote:
>> Maybe that was the PR the patch is about, but surely we can't treat
>> a memcpy (p, ..) like *p. Which means we'd use the declared type
>> of p only. And we can do so only for parameters (inter
On 29/09/2011, at 10:23 PM, Richard Guenther wrote:
> On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries wrote:
> + && SSA_NAME_IS_DEFAULT_DEF (expr)
> + && TREE_CODE (var) == PARM_DECL
> + && POINTER_TYPE_P (TREE_TYPE (var))
> + && TYPE_USER_ALIGN
On Wed, Oct 19, 2011 at 1:58 AM, Maxim Kuvyrkov wrote:
> On 29/09/2011, at 10:23 PM, Richard Guenther wrote:
>
>> On Thu, Sep 29, 2011 at 10:27 AM, Tom de Vries
>> wrote:
>
>> + && SSA_NAME_IS_DEFAULT_DEF (expr)
>> + && TREE_CODE (var) == PARM_DECL
>> + &&
On 09/24/2011 01:42 PM, Richard Guenther wrote:
> On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek wrote:
>> On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
>>> In the end I'd probably say the patch is ok without the option (thus
>>> turned on by default), but if LC_GLOBAL_LOCALE
On Tue, Oct 25, 2011 at 2:22 PM, Tom de Vries wrote:
> On 09/24/2011 01:42 PM, Richard Guenther wrote:
>> On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek wrote:
>>> On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the patch is ok without the optio
On 26/10/11 12:19, Richard Guenther wrote:
> On Tue, Oct 25, 2011 at 2:22 PM, Tom de Vries wrote:
>> On 09/24/2011 01:42 PM, Richard Guenther wrote:
>>> On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek wrote:
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
> In the end I
> * expr.c (get_object_or_type_alignment): Remove static.
> * expr.h (get_object_or_type_alignment): Declare.
I did that this morning (and also added an assertion in the function).
--
Eric Botcazou
On Tue, Sep 20, 2011 at 1:13 PM, Tom de Vries wrote:
> Hi Richard,
>
> I have a patch for PR43814. It introduces an option that assumes that function
> arguments of pointer type are aligned, and uses that information in
> tree-ssa-ccp. This enables the memcpy in pr43814-2.c to be inlined.
>
> I te
On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
> In the end I'd probably say the patch is ok without the option (thus
> turned on by default), but if LC_GLOBAL_LOCALE is part of the
> glibc ABI then we clearly can't do this.
Yes, LC_GLOBAL_LOCALE is part of glibc ABI. I guess w
On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek wrote:
> On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
>> In the end I'd probably say the patch is ok without the option (thus
>> turned on by default), but if LC_GLOBAL_LOCALE is part of the
>> glibc ABI then we clearly can't do
35 matches
Mail list logo
