On 11/2/21 2:18 PM, Christoph Müllner wrote:
On Tue, Nov 2, 2021 at 9:15 PM Vineet Gupta wrote:
On 11/2/21 1:09 PM, Christoph Müllner wrote:
Without overlap_op_by_pieces we get:
8e: 00053023sd zero,0(a0)
92: 00052423sw zero,8(a0)
9
On Tue, Nov 2, 2021 at 9:15 PM Vineet Gupta wrote:
>
>
>
> On 11/2/21 1:09 PM, Christoph Müllner wrote:
> Without overlap_op_by_pieces we get:
> 8e: 00053023sd zero,0(a0)
> 92: 00052423sw zero,8(a0)
> 96: 00051623
On 11/2/21 1:09 PM, Christoph Müllner wrote:
Without overlap_op_by_pieces we get:
8e: 00053023sd zero,0(a0)
92: 00052423sw zero,8(a0)
96: 00051623sh zero,12(a0)
9a: 00050723sb zero,14(a0
On Tue, Nov 2, 2021 at 8:27 PM Vineet Gupta wrote:
>
> On 7/22/21 6:29 AM, Kito Cheng via Gcc-patches wrote:
> > Could you add a testcase? Otherwise LGTM.
> >
> > Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
> > void foo(char *dst){
> > __builtin_memset(dst, 0, 15);
> > }
> >
> > On
On 7/22/21 6:29 AM, Kito Cheng via Gcc-patches wrote:
Could you add a testcase? Otherwise LGTM.
Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
void foo(char *dst){
__builtin_memset(dst, 0, 15);
}
On Thu, Jul 22, 2021 at 8:53 PM Christoph Muellner via Gcc-patches
wrote:
This patch
On Mon, 16 Aug 2021 11:56:05 PDT (-0700), pins...@gmail.com wrote:
On Mon, Aug 16, 2021 at 10:10 AM Palmer Dabbelt wrote:
On Mon, 16 Aug 2021 09:29:16 PDT (-0700), Kito Cheng wrote:
>> > Could you submit v3 patch which is v1 with overlap_op_by_pieces field,
>> > testcase from v2 and add a few
On Mon, Aug 16, 2021 at 10:10 AM Palmer Dabbelt wrote:
>
> On Mon, 16 Aug 2021 09:29:16 PDT (-0700), Kito Cheng wrote:
> >> > Could you submit v3 patch which is v1 with overlap_op_by_pieces field,
> >> > testcase from v2 and add a few more comments to describe the field?
> >> >
> >> > And add an -
On Mon, 16 Aug 2021 09:29:16 PDT (-0700), Kito Cheng wrote:
> Could you submit v3 patch which is v1 with overlap_op_by_pieces field,
> testcase from v2 and add a few more comments to describe the field?
>
> And add an -mtune=ultra-size to make it able to test without change
> other behavior?
>
>
> > Could you submit v3 patch which is v1 with overlap_op_by_pieces field,
> > testcase from v2 and add a few more comments to describe the field?
> >
> > And add an -mtune=ultra-size to make it able to test without change
> > other behavior?
> >
> > Hi Palmer:
> >
> > Are you OK with that?
>
> I'm
On Mon, 16 Aug 2021 03:02:42 PDT (-0700), Kito Cheng wrote:
HI Christoph:
Could you submit v3 patch which is v1 with overlap_op_by_pieces field,
testcase from v2 and add a few more comments to describe the field?
And add an -mtune=ultra-size to make it able to test without change
other behavior
HI Christoph:
Could you submit v3 patch which is v1 with overlap_op_by_pieces field,
testcase from v2 and add a few more comments to describe the field?
And add an -mtune=ultra-size to make it able to test without change
other behavior?
Hi Palmer:
Are you OK with that?
On Sat, Aug 14, 2021 at
Ping.
On Thu, Aug 5, 2021 at 11:11 AM Christoph Müllner wrote:
>
> Ping.
>
> On Thu, Jul 29, 2021 at 9:36 PM Christoph Müllner
> wrote:
> >
> > On Thu, Jul 29, 2021 at 8:54 PM Palmer Dabbelt wrote:
> > >
> > > On Tue, 27 Jul 2021 02:32:12 PDT (-0700), cmuell...@gcc.gnu.org wrote:
> > > > Ok, s
Ping.
On Thu, Jul 29, 2021 at 9:36 PM Christoph Müllner wrote:
>
> On Thu, Jul 29, 2021 at 8:54 PM Palmer Dabbelt wrote:
> >
> > On Tue, 27 Jul 2021 02:32:12 PDT (-0700), cmuell...@gcc.gnu.org wrote:
> > > Ok, so if I understand correctly Palmer and Andrew prefer
> > > overlap_op_by_pieces to be
On Thu, Jul 29, 2021 at 8:54 PM Palmer Dabbelt wrote:
>
> On Tue, 27 Jul 2021 02:32:12 PDT (-0700), cmuell...@gcc.gnu.org wrote:
> > Ok, so if I understand correctly Palmer and Andrew prefer
> > overlap_op_by_pieces to be controlled
> > by its own field in the riscv_tune_param struct and not by th
On Tue, 27 Jul 2021 02:32:12 PDT (-0700), cmuell...@gcc.gnu.org wrote:
Ok, so if I understand correctly Palmer and Andrew prefer
overlap_op_by_pieces to be controlled
by its own field in the riscv_tune_param struct and not by the field
slow_unaligned_access in this struct
(i.e. slow_unaligned_acc
Ok, so if I understand correctly Palmer and Andrew prefer
overlap_op_by_pieces to be controlled
by its own field in the riscv_tune_param struct and not by the field
slow_unaligned_access in this struct
(i.e. slow_unaligned_access==false is not enough to imply
overlap_op_by_pieces==true).
I don't h
On Mon, 26 Jul 2021 03:05:21 PDT (-0700), Andrew Waterman wrote:
On Thu, Jul 22, 2021 at 10:27 AM Palmer Dabbelt wrote:
On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> Could you add a testcase? Otherwise LGTM.
>
> Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp6
On Thu, Jul 22, 2021 at 10:27 AM Palmer Dabbelt wrote:
>
> On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Could you add a testcase? Otherwise LGTM.
> >
> > Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
> > void foo(char *dst){
> >__builtin_memset(dst, 0,
LGTM, but I would like to wait Palmer's ack.
I am fine with current scheme, just check riscv_slow_unaligned_access_p,
in case we have performance issue, we can consider change mtune's
slow_unaligned_access field to a number rather than a boolean value,
so that we can have better cost model for tha
I have added tests for memset and memcpy.
Additionally, I have added a test to ensure that -mstrict-align is
still working.
I've run the complete GCC test suite with and without the resulting
patch with no regressions
(rv32imac/ilp32/medlow, rv32imafdc/ilp32d/medlow,
rv64imac/lp64/medlow, rv64imafd
On Thu, Jul 22, 2021 at 7:27 PM Palmer Dabbelt wrote:
>
> On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > Could you add a testcase? Otherwise LGTM.
> >
> > Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
> > void foo(char *dst){
> >__builtin_memset(dst, 0, 1
On Thu, 22 Jul 2021 06:29:46 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Could you add a testcase? Otherwise LGTM.
Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
void foo(char *dst){
__builtin_memset(dst, 0, 15);
}
I'd like to see:
* Test results. This is only on for one target ri
Could you add a testcase? Otherwise LGTM.
Option: -O2 -mtune=thead-c906 -march=rv64gc -mabi=lp64
void foo(char *dst){
__builtin_memset(dst, 0, 15);
}
On Thu, Jul 22, 2021 at 8:53 PM Christoph Muellner via Gcc-patches
wrote:
>
> This patch enables the overlap-by-pieces feature of the by-pieces
This patch enables the overlap-by-pieces feature of the by-pieces
infrastructure for inlining builtins in case the target has set
riscv_slow_unaligned_access_p to false.
To demonstrate the effect for targets with fast unaligned access,
the following code sequences are generated for a 15-byte memse
24 matches
Mail list logo