On Fri, Oct 14, 2022 at 1:15 AM Palmer Dabbelt wrote:
> On Thu, 13 Oct 2022 15:39:39 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> >
> > On 10/11/22 17:31, Vineet Gupta wrote:
> >>
> >>>
> >>> I expect that the pressure for a proper fix upstream (instead of a
> >>> backward compatible compromise)
On Wed, Oct 12, 2022 at 2:15 AM Palmer Dabbelt wrote:
> On Tue, 11 Oct 2022 16:31:25 PDT (-0700), Vineet Gupta wrote:
> >
> >
> > On 10/11/22 13:46, Christoph Müllner wrote:
> >> On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt
> wrote:
> >>
> >> On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vinee
On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt wrote:
> On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
> > Hi Christoph, Kito,
> >
> > On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
> >> This series provides a cleanup of the current atomics implementation
> >> of RISC-V
On Fri, May 13, 2022 at 12:58 PM Florian Weimer wrote:
>
> * Christoph Müllner via Binutils:
>
> > I'd like to add two points to this topic and raise two questions.
> >
> > 1) Accepting vendor extensions = avoidance of fragmentation
> >
> > RISC-V implementors are actively encouraged to implement
On Wed, May 11, 2022 at 2:02 AM Palmer Dabbelt wrote:
>
> [Sorry for cross-posting to a bunch of lists, I figured it'd be best to
> have all the discussions in one thread.]
>
> We currently only support what is defined by official RISC-V
> specifications in the various GNU toolchain projects. The
On Fri, Jan 14, 2022 at 4:42 AM Palmer Dabbelt wrote:
>
> The code generated by -mcmodel=medany is defined to be
> position-independent, but is not guarnteed to function correctly when
> linked into position-independent executables or libraries. See the
> recent discussion at the psABI specificat
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 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
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, Aug 5, 2021 at 11:11 AM Christoph Müllner wrote:
>
> Ping.
>
> On Thu, Jul 29, 2021 at 4:33 PM Christoph Muellner
> wrote:
> >
> > The RISC-V cpymemsi expansion is called, whenever the by-pieces
> > infrastructure will not be taking care of the builtin expansion.
> > Currently, tha
Ping.
On Thu, Jul 29, 2021 at 4:33 PM Christoph Muellner
wrote:
>
> The RISC-V cpymemsi expansion is called, whenever the by-pieces
> infrastructure will not be taking care of the builtin expansion.
> Currently, that's the case for e.g. memcpy() with n <= 24 bytes.
> The code emitted by the by-pi
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
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
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, Jul 22, 2021 at 5:23 PM Christoph Müllner via Gcc-patches
> > wrote:
> > >
> > > On Thu, Jul 22, 2021 at 10:53 AM Kito Cheng wrote:
> > > >
> > > > It's my first time seeing this hook :p Did you mind des
prepare a v2, that uses enables overlap_op_by_pieces if
slow_unaligned_access==false.
>
> On Thu, Jul 22, 2021 at 5:23 PM Christoph Müllner via Gcc-patches
> wrote:
> >
> > On Thu, Jul 22, 2021 at 10:53 AM Kito Cheng wrote:
> > >
> > > It's my first tim
On Thu, Jul 22, 2021 at 10:53 AM Kito Cheng wrote:
>
> It's my first time seeing this hook :p Did you mind describing when we
> need to set it to true?
> I mean when a CPU has some feature then we can/should set it to true?
The by-pieces infrastructure allows to inline builtins quite well and
use
On Thu, May 6, 2021 at 5:29 AM Jim Wilson wrote:
>
> On Fri, Apr 30, 2021 at 4:10 PM Christoph Müllner via Gcc-patches
> wrote:
>>
>> On Sat, May 1, 2021 at 12:48 AM Jeff Law wrote:
>> > On 4/26/2021 5:38 AM, Christoph Muellner via Gcc-patches wrote:
>>
On Mon, Apr 26, 2021 at 4:40 PM Kito Cheng wrote:
>
> This patch is a good and simple improvement which could be an independent
> patch.
>
> There is only 1 comment from me for this patch, could you also add @
> to cbranch pattern for floating mode, I would prefer make the
> gen_cbranch4 could ha
On Sat, May 1, 2021 at 12:48 AM Jeff Law wrote:
>
>
> On 4/26/2021 5:38 AM, Christoph Muellner via Gcc-patches wrote:
> > [ree] PR rtl-optimization/100264: Handle more PARALLEL SET expressions
> >
> > PR rtl-optimization/100264
> > * ree.c (get_sub_rtx): Ignore SET expressions wi
On Thu, Mar 4, 2021 at 1:19 AM Andrew Pinski wrote:
> On Wed, Mar 3, 2021 at 4:02 PM Christoph Müllner
> wrote:
> >
> > [CCing Andrew Pinski, who had the same question]
> >
> > On 2/15/21 1:12 PM, Richard Earnshaw wrote:
> > > On 09/12/2020 17:21, Christoph Müllner wrote:
> > >> From: Christoph
[CCing Andrew Pinski, who had the same question]
On 2/15/21 1:12 PM, Richard Earnshaw wrote:
> On 09/12/2020 17:21, Christoph Müllner wrote:
>> From: Christoph Muellner
>>
>> It is possible to call aarch64_declare_function_name() and
>> have cfun not set. Let's sanitize the access to this variabl
24 matches
Mail list logo
