Ping.
Thanks,
Wei.
On Tue, Dec 17, 2013 at 11:34 AM, Wei Mi wrote:
> Ping.
>
> Thanks,
> Wei.
>
> On Mon, Dec 9, 2013 at 9:54 PM, Wei Mi wrote:
>> Ping.
>>
>> Thanks,
>> wei.
>>
>> On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi wrote:
>>> bootstrap and regression of the updated patch pass.
>>>
>>> O
Ping.
Thanks,
Wei.
On Mon, Dec 9, 2013 at 9:54 PM, Wei Mi wrote:
> Ping.
>
> Thanks,
> wei.
>
> On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi wrote:
>> bootstrap and regression of the updated patch pass.
>>
>> On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi wrote:
>>> On Thu, Nov 21, 2013 at 12:19 AM, Zde
Ping.
Thanks,
wei.
On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi wrote:
> bootstrap and regression of the updated patch pass.
>
> On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi wrote:
>> On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
>> wrote:
>>> Hi,
>>>
This patch works on the intrinsic calls han
On Sat, Nov 23, 2013 at 4:05 PM, Wei Mi wrote:
> On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
> wrote:
>> Hi,
>>
>>> This patch works on the intrinsic calls handling issue in IVOPT mentioned
>>> here:
>>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>>>
>>> In find_interesting_uses
bootstrap and regression of the updated patch pass.
On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi wrote:
> On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
> wrote:
>> Hi,
>>
>>> This patch works on the intrinsic calls handling issue in IVOPT mentioned
>>> here:
>>> http://gcc.gnu.org/ml/gcc-patches/
On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
wrote:
> Hi,
>
>> This patch works on the intrinsic calls handling issue in IVOPT mentioned
>> here:
>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>>
>> In find_interesting_uses_stmt, it changes
>>
>> arg = expr
>> __builtin_xxx (arg)
>
On Sat, Nov 23, 2013 at 1:57 AM, Wei Mi wrote:
> On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi wrote:
>>> I think the problem can be showed by below example:
>>> struct tag
>>> {
>>> int a[10];
>>> int b;
>>> };
>>> struct tag s;
>>> int foo(int len)
>>> {
>>> int i = 0;
>>> int sum = 0;
>>>
On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi wrote:
>> I think the problem can be showed by below example:
>> struct tag
>> {
>> int a[10];
>> int b;
>> };
>> struct tag s;
>> int foo(int len)
>> {
>> int i = 0;
>> int sum = 0;
>> for (i = 0; i < len; i++)
>> sum += barr (&s.a[i]);
>>
>>
> I think the problem can be showed by below example:
> struct tag
> {
> int a[10];
> int b;
> };
> struct tag s;
> int foo(int len)
> {
> int i = 0;
> int sum = 0;
> for (i = 0; i < len; i++)
> sum += barr (&s.a[i]);
>
> return sum;
> }
> The dump before IVOPT is like:
>
> :
>
On Fri, Nov 22, 2013 at 6:11 AM, Zdenek Dvorak wrote:
> Hi,
>
>> >> > If a pointer typed use is plainly value passed to a func call, it is
>> >> > not an address use, right? But as you said, x86 lea may help here.
>> >>
>> >> But that's what you are matching ... (well, for builtins you know
>> >>
On Fri, Nov 22, 2013 at 10:11 PM, Zdenek Dvorak
wrote:
> Hi,
>
>> >> > If a pointer typed use is plainly value passed to a func call, it is
>> >> > not an address use, right? But as you said, x86 lea may help here.
>> >>
>> >> But that's what you are matching ... (well, for builtins you know
>> >>
Hi,
> >> > If a pointer typed use is plainly value passed to a func call, it is
> >> > not an address use, right? But as you said, x86 lea may help here.
> >>
> >> But that's what you are matching ... (well, for builtins you know
> >> will expand that to a memory reference).
> >>
> >> What I disli
On Fri, Nov 22, 2013 at 12:19 PM, Zdenek Dvorak
wrote:
> Hi,
>
>> > If a pointer typed use is plainly value passed to a func call, it is
>> > not an address use, right? But as you said, x86 lea may help here.
>>
>> But that's what you are matching ... (well, for builtins you know
>> will expand th
Hi,
> > If a pointer typed use is plainly value passed to a func call, it is
> > not an address use, right? But as you said, x86 lea may help here.
>
> But that's what you are matching ... (well, for builtins you know
> will expand that to a memory reference).
>
> What I dislike in the patch is
On Thu, Nov 21, 2013 at 10:36 PM, Wei Mi wrote:
> On Thu, Nov 21, 2013 at 1:01 PM, Richard Biener
> wrote:
>> Wei Mi wrote:
>>>On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
>>> wrote:
Wei Mi wrote:
>> So what you are doing is basically not only rewriting memory
>references
>
On Thu, Nov 21, 2013 at 1:01 PM, Richard Biener
wrote:
> Wei Mi wrote:
>>On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
>> wrote:
>>> Wei Mi wrote:
> So what you are doing is basically not only rewriting memory
references
> to possibly use TARGET_MEM_REF but also address uses to us
On Thu, Nov 21, 2013 at 8:26 AM, Wei Mi wrote:
> Hi,
>
> This patch works on the intrinsic calls handling issue in IVOPT mentioned
> here:
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>
> In find_interesting_uses_stmt, it changes
>
> arg = expr
> __builtin_xxx (arg)
>
> to
>
> arg =
Wei Mi wrote:
>On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
> wrote:
>> Wei Mi wrote:
So what you are doing is basically not only rewriting memory
>>>references
to possibly use TARGET_MEM_REF but also address uses to use
&TARGET_MEM_REF. I think this is a good thing in general
On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
wrote:
> Wei Mi wrote:
>>> So what you are doing is basically not only rewriting memory
>>references
>>> to possibly use TARGET_MEM_REF but also address uses to use
>>> &TARGET_MEM_REF. I think this is a good thing in general
>>> (given instructio
Wei Mi wrote:
>> So what you are doing is basically not only rewriting memory
>references
>> to possibly use TARGET_MEM_REF but also address uses to use
>> &TARGET_MEM_REF. I think this is a good thing in general
>> (given instructions like x86 lea) and I would not bother
>distinguishing
>> the d
> So what you are doing is basically not only rewriting memory references
> to possibly use TARGET_MEM_REF but also address uses to use
> &TARGET_MEM_REF. I think this is a good thing in general
> (given instructions like x86 lea) and I would not bother distinguishing
> the different kind of uses.
Thanks for the comments.
Regards,
Wei.
On Thu, Nov 21, 2013 at 12:48 AM, Bin.Cheng wrote:
> I don't know very much about the problem but willing to study since I
> am looking into IVO recently :)
>
>> --- tree-ssa-loop-ivopts.c (revision 204792)
>> +++ tree-ssa-loop-ivopts.c (working c
On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
wrote:
> Hi,
>
>> This patch works on the intrinsic calls handling issue in IVOPT mentioned
>> here:
>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>>
>> In find_interesting_uses_stmt, it changes
>>
>> arg = expr
>> __builtin_xxx (arg)
>
I don't know very much about the problem but willing to study since I
am looking into IVO recently :)
> --- tree-ssa-loop-ivopts.c (revision 204792)
> +++ tree-ssa-loop-ivopts.c (working copy)
> @@ -135,6 +135,8 @@ struct iv
>tree ssa_name; /* The ssa name with the value. */
>
Hi,
> This patch works on the intrinsic calls handling issue in IVOPT mentioned
> here:
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>
> In find_interesting_uses_stmt, it changes
>
> arg = expr
> __builtin_xxx (arg)
>
> to
>
> arg = expr;
> tmp = addr_expr (mem_ref(arg));
> __bui
Hi,
This patch works on the intrinsic calls handling issue in IVOPT mentioned here:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
In find_interesting_uses_stmt, it changes
arg = expr
__builtin_xxx (arg)
to
arg = expr;
tmp = addr_expr (mem_ref(arg));
__builtin_xxx (tmp, ...)
So mem_r
26 matches
Mail list logo
