On Thu, 05 Jul 2018 05:00:20 PDT (-0700), sebastian.hu...@embedded-brains.de
wrote:
* config.guess: Sync with upstream version 2018-06-26.
* config.sub: Sync with upstream version 2018-07-02.
---
config.guess | 6 +++---
config.sub | 8 +++-
2 files changed, 10 insertions(
On Thu, 01 Jun 2023 09:48:47 PDT (-0700), jeffreya...@gmail.com wrote:
On 6/1/23 01:01, juzhe.zh...@rivai.ai wrote:
I plan to implement BF16 vector in GCC but still waiting for ISA
ratified since GCC policy doesn't allow un-ratified ISA.
Right. So those specs need to move along further befor
On Tue, 13 Jun 2023 10:41:00 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 6/13/23 00:41, Jin Ma wrote:
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_compute_frame_info): Allocate frame for
FCSR.
(riscv_for_each_saved_reg): Save and restore FCSR in interrupt
functions.
On Wed, 12 Jul 2023 09:02:06 PDT (-0700), jeffreya...@gmail.com wrote:
On 7/11/23 21:30, juzhe.zh...@rivai.ai wrote:
LGTM
OK for the trunk.
I'd like to make sure Kito is OK with this. IIUC the "pass through
unknown extensions" behavior is deliberate. It's not what I would have
done, but
On Thu, 13 Jul 2023 07:01:26 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>
>
> On 7/13/23 01:47, Richard Biener wrote:
>> On Thu, Jul 13, 2023 at 1:30â¯AM éå±
å² wrote:
>>>
>>> I notice vectorizable_call in Loop Vectorizer.
>>> It's vectorizing CALL function for example like fmax/fmin.
>>> Fr
On Thu, 13 Jul 2023 19:02:05 PDT (-0700), li...@eswincomputing.com wrote:
When generating the gen_and3 function based on the and3
template, it produces the expression emit_insn (gen_rtx_SET (operand0,
gen_rtx_AND (, operand1, operand2)));, which is identical to the
portion I removed in this patch
bably fine then, but
we might have some code floating around we could toss...
On Fri, Jul 14, 2023 at 10:34 AM Palmer Dabbelt wrote:
On Thu, 13 Jul 2023 19:02:05 PDT (-0700), li...@eswincomputing.com wrote:
> When generating the gen_and3 function based on the and3
> template, it p
/
-/* { dg-final { scan-assembler-not "lw" } } */
+/* { dg-final { scan-assembler-not "\tsw\t" } } */
+/* { dg-final { scan-assembler-not "\tfld\t" } } */
+/* { dg-final { scan-assembler-not "\tfsd\t" } } */
+/* { dg-final { scan-assembler-not "\tlw\t" } } */
I think that autovec one is the only possible dependency that might have snuck
in, so we should be safe otherwise. Thanks!
Reviewed-by: Palmer Dabbelt
On Tue, 25 Jul 2023 11:01:54 PDT (-0700), Patrick O'Neill wrote:
Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by
Jeff Law.
If there aren't any objections I'll commit this cherry-picked series
on Thursday (July 27th).
+Jakub
According to the "GCC 13.1.1 Status Report (2023
On Tue, 25 Jul 2023 12:50:48 PDT (-0700), ja...@redhat.com wrote:
On Tue, Jul 25, 2023 at 11:01:54AM -0700, Patrick O'Neill wrote:
Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by
Jeff Law.
If there aren't any objections I'll commit this cherry-picked series
on Thursday (Jul
On Tue, 25 Jul 2023 14:02:24 PDT (-0700), jeffreya...@gmail.com wrote:
On 7/25/23 13:50, Jakub Jelinek wrote:
On Tue, Jul 25, 2023 at 11:01:54AM -0700, Patrick O'Neill wrote:
Discussed during the weekly RISC-V GCC meeting[1] and pre-approved by
Jeff Law.
If there aren't any objections I'll co
On Fri, 21 Jul 2023 11:47:58 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 7/21/23 12:31, Palmer Dabbelt wrote:
(define_expand "len_mask_gather_load"
[(match_operand:VNX1_QHSD 0 "register_operand")
- (match_operand 1 "pmode_reg_or_0_operand")
+ (match_opera
On Wed, 26 Jul 2023 08:34:14 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
I would say LCM/PRE is the key of this set of static rounding model
intrinsic, otherwise I think it's will push people to using dynamic with
fesetrouding mode or inline asm to set the rounding mode for performance
issue - it
gcc/ChangeLog
* config.gcc (riscv): Accept rv64e and lp64e.
* config/riscv/arch-canonicalize: Likewise.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Likewise.
* config/riscv/riscv-opts.h (riscv_abi_type): Likewise.
* config/riscv/riscv.cc (riscv_optio
On Tue, 12 Jul 2022 22:09:53 PDT (-0700), Palmer Dabbelt wrote:
gcc/ChangeLog
* config.gcc (riscv): Accept rv64e and lp64e.
* config/riscv/arch-canonicalize: Likewise.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Likewise.
* config/riscv/riscv-opts.h
On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote:
Generally I agree we should fix that by GCC driver rather than ld
emulation, but I think this should be reverted with the -L path fix,
otherwise that will break multilib o
On Tue, 10 May 2022 17:01:26 PDT (-0700), 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 pro
On Thu, 21 Jul 2022 02:03:35 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
LGTM, will merge once binuils part merge.
+Nelson, in case he's already planning on handling those. If not then
they're not in my inbox, so just poke me if you want me to review them.
Also some comments on the patch be
These two patterns were independent, but exactly match the semantics of
X. Replace them with a single paramaterized pattern. Thanks to Andrew
for pointing this one out over IRC.
gcc/ChangeLog
* config/riscv/riscv.md (eh_set_lr_): New pattern.
(eh_set_lr_si): Remove.
(eh_
There's no operand 2 here, so referencing it doesn't make sense. I
couldn't find a way to trigger bad assembly output so I don't have a
test.
gcc/ChangeLog
PR target/106543
* config/riscv/riscv.md (sge_): Remove
reference to non-existent operand.
---
No new failures on th
On Thu, 03 Aug 2023 08:05:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
I'm using this hunk locally to more thoroughly exercise the zicond paths
due to inaccuracies elsewhere in the costing model. It was never
supposed to be part of the costing commit though. And as we've seen
it's causing pr
Ztso psABI mappings[1].
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/391
Which was just merged this morning, we talked some in the GCC patchwork
sync. IIUC that was the last blocker for getting the implementations
merged, so
Reviewed-by: Palmer Dabbelt
Thanks!
2023-08-08 Pa
On Thu, 10 Aug 2023 19:12:06 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 5/29/23 06:46, Jeff Law wrote:
>
>
> On 5/29/23 05:01, Jin Ma wrote:
>> Reference:
>> https://github.com/gcc-mirror/gcc/commit/d0bc0cb66bcb0e6a5a5a31a9e900e8ccc98e34e5
>>
>> RISC-V should also be implemented to handle
On Thu, 10 Aug 2023 20:19:02 PDT (-0700), jeffreya...@gmail.com wrote:
On 8/10/23 20:30, Palmer Dabbelt wrote:
Sorry for being lost here, but I'm not sure where TYPE_UNKNOWN comes
from. There's not a whole lot of instances in the code, and they all
seem to be doing something ve
On Fri, 11 Aug 2023 16:30:29 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 8/9/23 16:39, Tsukasa OI wrote:
On 2023/08/10 5:05, Jeff Law wrote:
I'd tend to think we do not want to expose the intrinsic unless the
right extensions are enabled -- even though the encoding is a no-op and
we coul
On Wed, 16 Aug 2023 15:59:13 PDT (-0700), jeffreya...@gmail.com wrote:
On 8/16/23 07:50, Robin Dapp wrote:
But if it's a float16 precision issue then I would have expected both
the computations for the lhs and rhs values to have suffered
similarly.
Yeah, right. I didn't look closely enough.
On Thu, 17 Aug 2023 10:10:38 PDT (-0700), Patrick O'Neill wrote:
On 8/16/23 21:36, Jeff Law wrote:
On 8/16/23 19:17, Patrick O'Neill wrote:
This adds new regression tests to ensure half-register rotations are
correctly optimized into rori instructions.
gcc/testsuite/ChangeLog:
* gcc.ta
On Thu, 17 Aug 2023 10:03:04 PDT (-0700), rdapp@gmail.com wrote:
Indeed all ANYLSF patterns have TARGET_HARD_FLOAT (==f extension) which
is incompatible with ZHINX or ZHINXMIN anyway. That should really be fixed
separately or at least clarified, maybe I'm missing something.
We've also got
+)
+{
+a[i] = (val & 1) ? (-val) >> 17 : val;
+val += b;
+}
+}
Unless I'm missing something it looks like we're missing at least Wc1 as
well, and maybe a few others?
Either way
Reviewed-by: Palmer Dabbelt
Thanks!
On Fri, 30 Jun 2023 17:25:54 PDT (-0700), Andrew Waterman wrote:
On Fri, Jun 30, 2023 at 5:13 PM Vineet Gupta wrote:
On 6/30/23 16:50, Andrew Waterman wrote:
> I don't believe this is correct; the subtraction is needed to account
> for the fact that the low part might be negative, resulting
On Sat, 01 Jul 2023 07:04:16 PDT (-0700), jeffreya...@gmail.com wrote:
On 7/1/23 02:00, Andrew Waterman wrote:
Yeah, that might end up being a false economy for superscalars.
In general, I wouldn't recommend spending too many cleverness beans on
non-Zba+Zbb implementations. Going forward,
On Tue, 31 Oct 2023 16:18:35 PDT (-0700), jeffreya...@gmail.com wrote:
On 10/31/23 12:35, Vineet Gupta wrote:
riscv_promote_function_mode doesn't promote a SI to DI for libcalls
case.
The fix is what generic promote_mode () in explow.cc does. I really
don't understand why the old code didn't
On Fri, 17 Feb 2023 06:02:40 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Hi all,
If we have division and remainder calculations with the same operands:
a = b / c;
d = b % c;
We can replace the calculation of remainder with multiplication +
subtraction, using the result from the previous div
On Sat, 18 Feb 2023 10:42:51 PST (-0800), pins...@gmail.com wrote:
On Sat, Feb 18, 2023 at 10:27 AM Palmer Dabbelt wrote:
On Fri, 17 Feb 2023 06:02:40 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> Hi all,
> If we have division and remainder calculations with the same operands:
>
>
On Sat, 18 Feb 2023 13:06:02 PST (-0800), jeffreya...@gmail.com wrote:
On 2/18/23 11:26, Palmer Dabbelt wrote:
On Fri, 17 Feb 2023 06:02:40 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Hi all,
If we have division and remainder calculations with the same operands:
a = b / c;
d = b % c
+= march=rv64imac/mabi=lp64/mcmodel=medany
-MULTILIB_REQUIRED += march=rv64imafdc/mabi=lp64d
+MULTILIB_REQUIRED += march=rv64imafd/mabi=lp64d/mcmodel=medany
MULTILIB_REQUIRED += march=rv64imafdc/mabi=lp64d/mcmodel=medany
Reviewed-by: Palmer Dabbelt
IMO it's fine to remove multilibs
We generate a handful of attributes by default, but they don't really
encode any useful information. We've broadly stopped ascribing any
meaning to them in binutils; but they trip up LLVM, older toolchains,
and users. So let's just turn them off by default. The old binaries
will still be floatin
issue, so the situation should be improved
soon.
If toolchains are just going to ignore then attributes then it's a
pretty good sign they're not useful.
Palmer Dabbelt 於 2023年2月24日 週五 10:29 寫道：
We generate a handful of attributes by default, but they don't really
enco
On Wed, 10 May 2023 08:24:40 PDT (-0700), rdapp@gmail.com wrote:
Hi,
this patch tries to improve the wrappers that emit either vlmax or
non-vlmax operations. Now, emit_len_op can be used to
emit a regular operation. Depending on whether a length != NULL
is passed either no VLMAX flags are
On Wed, 10 May 2023 11:50:32 PDT (-0700), rdapp@gmail.com wrote:
It's somewhat common for mail clients to treat "--" as a signature
deliminator, it's "---" that git uses as a comment deliminator.
It's in my muscle memory somehow. Always did it that way because I
didn't want the same delimi
On Wed, 10 May 2023 08:24:50 PDT (-0700), rdapp@gmail.com wrote:
> Hi,
>
> this patch splits off the shift patterns of the binop patterns.
> This is necessary as the scalar shifts require a Pmode operand
> as shift count. To this end, a new iterator any_int_binop_no_shift
> is introduced. At
On Wed, 10 May 2023 08:24:57 PDT (-0700), rdapp@gmail.com wrote:
> Hi,
>
> this patchs adds scan as well as execution tests for vectorized
> binary integer operations. It is based on Michael Collison's work
> and also includes scalar variants. The tests are not fully comprehensive
> as the ve
On Thu, 11 May 2023 07:21:30 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/11/23 04:33, Robin Dapp wrote:
"csr_operand" does seem wrong, though, as that just accepts constants.
Maybe "arith_operand" is the way to go? I haven't looked at the
V immediates though.
I was pondering changing the s
The vector shift immediates happen to have the same constraints as some
of the CSR-related operands, but it's a different usage. This adds a
name for them, so I don't get confused again next time.
gcc/ChangeLog:
* config/riscv/autovec.md (shifts): Use v_uimm_operand.
* config/ris
The vector shift immediates happen to have the same constraints as some
of the CSR-related operands, but it's a different usage. This adds a
name for them, so I don't get confused again next time.
gcc/ChangeLog:
* config/riscv/autovec.md (shifts): Use
vector_scalar_shift_operan
On Thu, 11 May 2023 15:00:48 PDT (-0700), juzhe.zh...@rivai.ai wrote:
;; V has 32-bit unsigned immediates. This happens to be the same constraint asIt
should be 5-bit unsigned immediates>> ; the csr_operand, but it's not CSR
related.
(define_predicate "v_uimm_operand"
(match_operand 0 "csr
A few of us were talking about test-related issues in the patchwork meeting
this morning. I bumped to trunk and did a full rebuild, I'm getting the
following (it's in riscv-systems-ci/riscv-gnu-toolchain). This is about what I
remember seeing last time I ran the tests, which was a week or so ago
On Tue, 16 May 2023 17:16:11 PDT (-0700), Vineet Gupta wrote:
On 5/16/23 16:06, Palmer Dabbelt wrote:
A few of us were talking about test-related issues in the patchwork
meeting
this morning. I bumped to trunk and did a full rebuild, I'm getting the
following (it's in riscv-system
On Tue, 16 May 2023 18:04:37 PDT (-0700), Vineet Gupta wrote:
+ Christoph, Jiawei
On 5/16/23 17:20, Palmer Dabbelt wrote:
We really need to add some CI around RV toolchains to trip on these
sooner !
Sounds like you're volunteering to set one up?
Patrick's github CI patch see
On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:
On 5/16/23 19:29, Palmer Dabbelt wrote:
I think the most pressing need is bleeding edge gcc regression tracking.
@Jeff is anything setup on sourceware and/or usable ? I thought they
do have existing bots for some arches to spin up
On Tue, 16 May 2023 19:07:01 PDT (-0700), juzhe.zh...@rivai.ai wrote:
Oh, I see. Kito has add /* { dg-do run { target { riscv_vector } } } */
But not all RVV tests has use this and I not sure whether it can work.
I think Kito can answer it.
If yes, I think we should add all of them.
Unless I'm
On Tue, 16 May 2023 19:32:21 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/16/23 20:05, Palmer Dabbelt wrote:
On Tue, 16 May 2023 19:00:12 PDT (-0700), Jeff Law wrote:
On 5/16/23 19:29, Palmer Dabbelt wrote:
I think the most pressing need is bleeding edge gcc regression
tracking
On Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:
On 5/16/23 19:21, Kito Cheng wrote:
Palmer:
For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233
That only helps if using bleeding edge toolchain scripts (which I
regula
On Tue, 16 May 2023 19:51:48 PDT (-0700), Patrick O'Neill wrote:
On 5/16/23 19:47, Palmer Dabbelt wrote:
On Tue, 16 May 2023 19:46:28 PDT (-0700), Vineet Gupta wrote:
On 5/16/23 19:21, Kito Cheng wrote:
Palmer:
For short-term, this should help your internal test:
https://github.com/
On Tue, 16 May 2023 20:08:26 PDT (-0700), Vineet Gupta wrote:
On 5/16/23 19:53, Palmer Dabbelt wrote:
Probably, I'll go try and bump stuff and see if it works...
Word of caution: Best to not disturb your existing setup, a try a fresh
checkout first
Even easier, I think I can get away
On Fri, 19 May 2023 09:33:34 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/18/23 14:57, Vineet Gupta wrote:
[part #2 of PR/109279]
SPEC2017 deepsjeng uses large constants which currently generates less than
ideal code. This fix improves codegen for large constants which have
same low and hi
x_insn (code_for_pred_mov (mode),
riscv_vector::RVV_UNOP, ops);
Reviewed-by: Palmer Dabbelt
as both cleanups look better to me. Thanks!
On Tue, 23 May 2023 18:34:00 PDT (-0700), juzhe.zh...@rivai.ai wrote:
Yeah. Can I merge it?
You built it? Then I'm fine with merging it.
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-24 09:32
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; jeffreyalaw; rdap
On Tue, 23 May 2023 18:37:39 PDT (-0700), juzhe.zh...@rivai.ai wrote:
Yes, I built it and regression has passed.
OK, thanks!
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-24 09:37
To: juzhe.zhong
CC: gcc-patches; Kito Cheng; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: Re
On Wed, 24 May 2023 16:12:20 PDT (-0700), Vineet Gupta wrote:
On 5/24/23 15:13, Vineet Gupta wrote:
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
PASS: gcc.target/riscv/zmmul-2.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-obj
ust revert it later.
On Sat, Aug 14, 2021 at 1:54 AM Christoph Müllner via Gcc-patches
wrote:
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:5
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?
>
>
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 fro
On Fri, 16 Sep 2022 16:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 9/6/22 05:39, Alexander Monakov via Gcc-patches wrote:
On Mon, 5 Sep 2022, Philipp Tomsich wrote:
+riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode mode_rep)
+{
+ /* On 64-bit targets, SImode register v
or to produce the optimized code.
The test cases check the correct generation of the fcvt instruction for
float/double to int/long/long long. Passed the test in riscv-linux.
Could this patch be committed?
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
Not sure if Kito had any comment
On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabbelt wrote:
I just happened to stuble on this one while trying to sort out the
RISC-V bits.
gcc/ChangeLog
* doc/tm.texi (TARGET_C_EXCESS_PRECISION): Add 16.
---
gcc/doc/tm.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Fri, 02 Sep 2022 18:28:10 PDT (-0700), Palmer Dabbelt wrote:
We don't yet support vectorization on RISC-V.
gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/gen-vect-34.c: Skip RISC-V targets.
---
gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c | 2 +-
1 file changed, 1 insertion(
On Fri, 09 Sep 2022 02:56:26 PDT (-0700), Kito Cheng wrote:
LGTM, seems like you have landed now, see you soon :)
Committed.
On Fri, Sep 9, 2022 at 5:44 PM Palmer Dabbelt wrote:
This fixes f19a327077e ("Support -fexcess-precision=16 which will enable
FLT_EVAL_METHOD_PROMOTE_TO_FL
On Sat, 24 Sep 2022 19:13:36 PDT (-0700), san...@codesourcery.com wrote:
On 9/18/22 02:47, Palmer Dabbelt wrote:
On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabbelt wrote:
I just happened to stuble on this one while trying to sort out the
RISC-V bits.
gcc/ChangeLog
* doc/tm.texi
On Fri, 30 Sep 2022 15:51:02 PDT (-0700), H.J. Lu wrote:
On Fri, Sep 30, 2022 at 3:25 PM Palmer Dabbelt wrote:
On Sat, 24 Sep 2022 19:13:36 PDT (-0700), san...@codesourcery.com wrote:
> On 9/18/22 02:47, Palmer Dabbelt wrote:
>> On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabb
As of 1214196da79 ("More gimple const/copy propagation opportunities"),
I'm getting some build failures during bootstrap
../../gcc/tree-ssa-dom.cc: In function ‘void record_edge_info(basic_block)’:
../../gcc/tree-ssa-dom.cc:689:27: error: ‘dst’ was not declared in this
scope; did you mean
On Fri, 30 Sep 2022 18:01:00 PDT (-0700), jeffreya...@gmail.com wrote:
On 9/30/22 18:57, Palmer Dabbelt wrote:
As of 1214196da79 ("More gimple const/copy propagation opportunities"),
I'm getting some build failures during bootstrap
../../gcc/tree-ssa-dom.cc: In
On Tue, 06 Sep 2022 03:39:02 PDT (-0700), manolis.tsa...@vrull.eu wrote:
This commit implements the target macros (TARGET_SHRINK_WRAP_*) that
enable separate shrink wrapping for function prologues/epilogues in
RISC-V.
Tested against SPEC CPU 2017, this change always has a net-positive
effect on
ting-point test failure in
gfortran. Looks like it predates this, but I'm trying to bisect it to
at least have a root cause before just ignoring it. I've got this
floating around on a branch and hopefully that'll remind me to commit
it after I sort that out.
Palmer Dabbelt
The C906 is by far the most widely available RISC-V processor, so let's
default to tuning for it.
gcc/ChangeLog
* config/riscv/riscv.h (RISCV_TUNE_STRING_DEFAULT): Change to
thead-c906.
* doc/invoke.texi (RISC-V -mtune): Change the default to
thead-c906.
---
This
y alignment at all. */
if (! DECL_USER_ALIGN (decl)
- && align_functions.levels[0].log > align
- && optimize_function_for_speed_p (cfun))
+ && align_functions.levels[0].log > align)
{
#ifdef ASM_OUTPUT_MAX_SKIP_ALIGN
int align_log = align_functions.levels[0].log;
Reviewed-by: Palmer Dabbelt
Though I'm not a global reviewer, so not sure how much that helps...
I found this when reading the documentation for Kito's recent patch.
>From the discussion it sounds like this is the desired behavior, so
let's document it.
gcc/doc/ChangeLog
* invoke.texi (-falign-functions): Mention __align__
---
gcc/doc/invoke.texi | 4 +++-
1 file changed, 3 insertio
On Fri, 07 Oct 2022 05:56:39 PDT (-0700), hubi...@ucw.cz wrote:
On Fri, Oct 7, 2022 at 6:04 AM Kito Cheng wrote:
>
> From: Monk Chiang
>
> Currnetly setting of -falign-functions=N will be ignored if the function
> is optimized for size or marked as cold function.
>
> However function alignment
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:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide p
I found this when reading the documentation for Kito's recent patch.
>From the discussion it sounds like this is the desired behavior, so
let's document it.
gcc/doc/ChangeLog
* invoke.texi (-falign-functions): Mention __align__
---
gcc/doc/invoke.texi | 4 +++-
1 file changed, 3 insertio
There were some recent discussions about the desired behavior of
-falign-functions, which is behaving as desired. This improves the
documentation to make that explicit.
Change since v1 <20221007134901.5078-1-pal...@rivosinc.com>:
* New patch 2 and 3
gcc/doc/ChangeLog
* invoke.texi (-falign-functions): Mention cold/size-optimized
functions.
---
gcc/doc/invoke.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a24798d5029..6af18ae9bfd 100644
--- a/gcc/doc/i
On Sun, 09 Oct 2022 23:07:21 PDT (-0700), richard.guent...@gmail.com wrote:
On Fri, Oct 7, 2022 at 3:50 PM Palmer Dabbelt wrote:
I found this when reading the documentation for Kito's recent patch.
From the discussion it sounds like this is the desired behavior, so
let's document i
This is implicitly mentioned in the docs, but there were some questions
in a recent patch. This makes it more exlicit that -falign-functions is
meant to be ignored under -Os.
gcc/doc/ChangeLog
* invoke.texi (-falign-functions): Mention -Os
---
gcc/doc/invoke.texi | 3 ++-
1 file changed
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), Vineet Gupta wrote:
> Hi Christoph, Kito,
>
> On 5/5/21 12:36,
On Thu, 17 Mar 2022 23:52:04 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Hi Shi-Hua:
Thanks, this patch is LGTM, but I would defer that until stage 1,
because the binutils part isn't merget yet.
IMO we should at least have a __riscv_ztso define, and ideally have the
relevent builtins ported (
l ping Nelson for the binutils
part.
On Tue, Mar 22, 2022 at 9:13 AM Palmer Dabbelt wrote:
On Thu, 17 Mar 2022 23:52:04 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> Hi Shi-Hua:
>
> Thanks, this patch is LGTM, but I would defer that until stage 1,
> because the binutils part i
On Tue, 29 Mar 2022 07:08:35 PDT (-0700), lewis.rev...@embecosm.com wrote:
Currently the existing libcalls for restoring registers have the
requirement that they must be tail called by the parent function, so
that they can safely return through the restored return address
register. This does impo
The RISC-V port requires libatomic to be linked in order to resolve
various atomic functions, which results in builds that have
"--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks.
Changing this to direct atomics breaks the ABI, this forces the auto
detection mutex-based atomics on
On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwak...@redhat.com wrote:
On 07/04/22 11:46 -0700, Palmer Dabbelt wrote:
The RISC-V port requires libatomic to be linked in order to resolve
various atomic functions, which results in builds that have
"--with-libstdcxx-lock-policy=auto" def
On Thu, 14 Apr 2022 08:22:05 PDT (-0700), jwak...@redhat.com wrote:
On Thu, 14 Apr 2022 at 16:18, Palmer Dabbelt wrote:
On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwak...@redhat.com wrote:
> On 07/04/22 11:46 -0700, Palmer Dabbelt wrote:
>>The RISC-V port requires libatomic to be
On Tue, 19 Apr 2022 23:13:15 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Does Asan work for RISC-V currently? It seems that '-fsanitize=address' is
still unsupported for RISC-V. If I add '--enable-libsanitizer' in Makefile.in
to reconfigure, there are compiling errors.
Is it because # libsaniti
This fires errors like
FAIL: g++.dg/opt/const7.C -std=c++14 scan-assembler-symbol-section symbol
b_var (found _ZL5b_var) has section ^\\.(const|rodata)|\\[RO\\] (found .srodata)
on RISC-V, where RO data can end up in the srodata section.
gcc/testsuite/ChangeLog:
* g++.dg/opt/cons
On Wed, 20 Apr 2022 18:41:08 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Hi Joshua:
[from the other thread: Thanks, no idea how I missed all those 32-bit
ports...]
Does Asan work for RISC-V currently? It seems that '-fsanitize=address' is
still unsupported for RISC-V. If I add '--enable-
On Tue, 18 Jan 2022 08:31:12 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Thanks Martin!
Yep. Seeing this go by, though, I think there's some English issues
with the original messages. I'd write it more like this, but I'm never
100% sure on these things:
diff --git a/gcc/common/config/r
ument that these may not
work.
[1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/245
[2]: https://sourceware.org/bugzilla/show_bug.cgi?id=28789
gcc/ChangeLog:
* doc/invoke.texi: Document the degree of position independence
that -mcmodel=medany affords.
Signed-off-
C 13 material. Please let me know
otherwise.
In any case OK to apply (when the time comes)?
IMO waiting is the right way to go, as if this does uncover any issues
they'll be a long-tail sort of thing. That way we'll at least have a
whole release cycle for folks to test on their hardwar
On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Hi!
riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
due to some aggressive linker optimizations).
I don't really understand the rest of this, but we do have a subset of
LEB128 (constant expression
On Thu, 20 Jan 2022 13:20:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On Thu, Jan 20, 2022 at 01:13:45PM -0800, Palmer Dabbelt wrote:
On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
>
On Thu, 20 Jan 2022 13:33:35 PST (-0800), Palmer Dabbelt wrote:
On Thu, 20 Jan 2022 13:20:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On Thu, Jan 20, 2022 at 01:13:45PM -0800, Palmer Dabbelt wrote:
On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> riscv*-*-* are
1 - 100 of 533 matches
Mail list logo
