g past
non-transparent blocks: That is taken care of by Robin's patch
"RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547]"
for a different yet related issue.
Reported-by: Heinrich Schuchardt
Signed-off-by: Vineet Gupta
PR target/119533
gcc/ChangeLog:
g past
non-transparent blocks: That is taken care of by Robin's patch
"RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547]"
or a different yet related issue.
Reported-by: Heinrich Schuchardt
Signed-off-by: Vineet Gupta
PR target/119533
gcc/ChangeLog:
* con
Hi Robin,
On 4/8/25 21:56, Robin Dapp wrote:
Yay ! It does work. Awesome.
I've uploaded the further reduced test to PR/119533
>>> Hmm, I'm seeing the same ICE as before with my patch. Did you happen
>>> to change
>>> something else on your local tree still?
Ye
On 4/8/25 16:32, Vineet Gupta wrote:
>>>>>> Yay ! It does work. Awesome.
>>>>>> I've uploaded the further reduced test to PR/119533
>>>>> Hmm, I'm seeing the same ICE as before with my patch. Did you happen to
>>>>> cha
On 4/8/25 13:47, Vineet Gupta wrote:
> On 4/8/25 12:27, Robin Dapp wrote:
>>>>> Yay ! It does work. Awesome.
>>>>> I've uploaded the further reduced test to PR/119533
>>>> Hmm, I'm seeing the same ICE as before with my patch. Did you happen
On 4/8/25 12:27, Robin Dapp wrote:
Yay ! It does work. Awesome.
I've uploaded the further reduced test to PR/119533
>>> Hmm, I'm seeing the same ICE as before with my patch. Did you happen to
>>> change
>>> something else on your local tree still?
Yeah I had some debug stuff lying aro
On 4/8/25 02:12, Robin Dapp wrote:
>> However we still see lift up using those blocks - the earliest set computed
>> contained the supposedly elided bbs.
>>
>> Try lift up 0.
>>
>> earliest:
>> Edge(bb 16 -> bb 17): n_bits = 3, set = {1 }
>>
>> Try lift up 1.
>>
>>
On 3/31/25 21:54, Jeff Law wrote:
> And if that's the case then you can't simply skip an abnormal edge. You
> have to do something sensible.
>
> That "something sensible" has traditionally been to ensure there is
> never a need propagated to an edge since you can't insert on an abnormal
> criti
On 4/1/25 17:44, Jeff Law wrote:
> On 4/1/25 12:15 PM, Vineet Gupta wrote:
>> On 3/31/25 23:48, Heinrich Schuchardt wrote:
>>> On 3/30/25 01:49, Vineet Gupta wrote:
>>>> changes since v2
>>>>- dump log sanfu
>>>>
>>>> ---
>&
On 3/29/25 17:58, Jeff Law wrote:
> On 3/29/25 6:49 PM, Vineet Gupta wrote:
>> changes since v2
>> - dump log sanfu
>>
>> ---
>> vsetvl phase4 uses LCM guided info to insert VSETVL insns.
>> It has an additional loop to insert missing vsetvls on certain e
On 3/31/25 23:48, Heinrich Schuchardt wrote:
> On 3/30/25 01:49, Vineet Gupta wrote:
>> changes since v2
>> - dump log sanfu
>>
>> ---
>> vsetvl phase4 uses LCM guided info to insert VSETVL insns.
>> It has an additional loop to insert missing vsetvls on
On 3/31/25 12:39, Jeff Law wrote:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): skip
EDGE_ABNORMAL.
gcc/testsuite/ChangeLog:
* go.dg/pr119533-riscv.go: New test.
>>> So presumably it wants to insert on the EH edge for a reason. Just
>>> skipping t
On 3/29/25 13:36, Andreas Schwab wrote:
>> + if (eg->flags & EDGE_ABNORMAL)
>> +{
>> + fprintf (dump_file, "\nskipping EDGE_ABNORMAL\n");
> This will crash if dump_file is NULL.
Sorry, last minute update.
Fixed, v2 posted.
Thx,
-Vineet
|0 / 0 |
PR target/119533
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): skip
EDGE_ABNORMAL.
gcc/testsuite/ChangeLog:
* go.dg/pr119533-riscv.go: New test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-vsetvl.cc
/119533
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): skip
EDGE_ABNORMAL.
gcc/testsuite/ChangeLog:
* go.dg/pr119533-riscv.go: New test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-vsetvl.cc | 6 +-
gcc/testsuite/go.dg/pr119533
splitter.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117722.c: Adjust output insn.
* gcc.target/riscv/rvv/autovec/pr119224.c: Add new test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/autovec.md | 3 ++-
.../gcc.target/riscv/rvv/autovec/pr117722.c
On 3/25/25 00:45, Robin Dapp wrote:
>> - "TARGET_VECTOR"
>> + "TARGET_VECTOR && 0"
> Would you mind adding a comment here before committing, maybe even reference
> the PR? Not that we want to keep this around for long anyway but just to
> make
> sure :)
Of course, I pondered the same but the
splitter.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117722.c: Adjust output insn.
* gcc.target/riscv/rvv/autovec/pr119224.c: Add new test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/autovec.md | 2 +-
.../gcc.target/riscv/rvv/autovec/pr117722.c
Hi,
On 12/3/24 03:02, Jiawei wrote:
> This patch series introduces support for RISC-V Profiles RV20, RV22[1],
> and RV23[2][3].The updates enhance compatibility and streamline the process
> of leveraging RISC-V Profiles through the -march option. These additions
> are in line with the RISC-V stand
On 3/3/25 15:18, Andrew Waterman wrote:
>> So in some convoluted way both the above scenarios have callee-saved
>> semantics
>> for FRM, except for the leaf function which unconditionally sets FRM where
>> this
>> save/restore is not done.
> I don't follow the last part about leaf functions. Unl
Hi Pan, Andrew
I'm trying to understand the semantics of FRM as it intersects with calling
convention.
psABI is not explicit about it and refers to C standard [1]
> On 2/14/25 03:39, Li, Pan2 wrote:
[snip]
> With option "-march=rv64gcv_zvfh -O3"
>
> 10 │ vxrm:
> 11 │ csrwi vxrm,
On 2/24/25 16:07, Edwin Lu wrote:
> See [1] thread for original patch which spawned this one.
>
> We are currently seeing the following code where we perform a vsetvl
> before a branching instruction against the avl.
>
> vsetvli a5,a1,e32,m1,tu,ma
> vle32.v v2,0(a0)
> sub
On 2/13/25 20:46, Jeff Law wrote:
>> BTW what exactly is speculative scheduling ? As in what is it actually
>> trying to
>> schedule ahead ?
> In simplest terms assume we have this kind of graph
>
> 0
> / \
>1-->2
>
>
> The scheduler knows how to build scheduling regions, essentially
On 2/14/25 04:58, Jeff Law wrote:
> I'd guess it more work than it'd be worth. We're just not seeing
> vsetvls being all that problematical on our design. I do see a lot of
> seemingly gratutious changes in the vector config, but when we make
> changes to fix that we generally end up with wors
On 2/13/25 14:17, Robin Dapp wrote:
Other thoughts?
>>> The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff
>>> we can't/don't model in the pipeline, but I have no idea how to model
>>> the VL=0 case there.
>> Maybe so, but what Edwin is doing looks sensible enough. It
.
* gcc.target/riscv/rvv/autovec/vls/trunc-3.c: Ditto.
* gcc.target/riscv/rvv/base/simplify-vdiv.c: Ditto.
* gcc.target/riscv/rvv/base/unop_v_constraint-1.c: Ditto.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/vector.md| 16 ++---
.../cond
On 2/8/25 23:02, Jeff Law wrote:
> On 2/7/25 9:34 PM, Vineet Gupta wrote:
>> A couple of Vector pseudoinstructions use x0 scalar which being regfile
>> crosser could be inefficient on certain wider uarches.
>>
>> Use the imm 0 form, which should be functionally equ
: Vineet Gupta
---
gcc/config/riscv/vector.md| 16 ++---
.../cond/cond_convert_int2int-rv32-1.c| 4 ++--
.../cond/cond_convert_int2int-rv32-2.c| 4 ++--
.../cond/cond_convert_int2int-rv64-1.c| 4 ++--
.../cond/cond_convert_int2int-rv64-2.c
-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.opt| 4
gcc/config/riscv/vector.md| 20 +---
.../cond/cond_convert_int2int-rv32-1.c| 4 ++--
.../cond/cond_convert_int2int-rv32-2.c| 4 ++--
.../cond/cond_convert_int2int-rv64
On 1/26/25 05:33, pan2...@intel.com wrote:
> From: Pan Li
>
> After we add the frm register to the global_regs, we may not need to
> define_insn that volatile to emit the frm restore insns. The
> cooperatively-managed global register will help to handle this, instead
> of emit the volatile define
aborts in
glibc:round_away() due to non-canonical rounding mode showing up,
"leaking" earlier in the call chain because such rounding mode
save/restore was getting eliminated.
PR target/118646
gcc/testsuite/ChangeLog:
* gfortran.target/riscv/rvv/pr118646.f90 (New Test).
S
On 1/26/25 05:29, Jeff Law wrote:
>
> On 1/24/25 3:12 PM, Vineet Gupta wrote:
>> RV-Vector FP-INT insns use the rounding mode in FRM register which if
>> explicitly set for V insn needs, is saved/restored (although from the
>> psABI CC Spec, it is not clear if it ac
get/118103
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_emit_frm_mode_set): Use volatile
fsrmi restore.
gcc/testsuite/ChangeLog:
* gfortran.target/riscv/rvv/pr118646.f90 (New Test).
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 2 +-
.../
On 1/20/25 19:07, Li, Pan2 wrote:
> Agree, the mode-switch will take care of the frm when meet a call (covered by
> testcase already).
>
>5 │
>6 │ extern size_t normalize_vl_1 (size_t vl);
>7 │ extern size_t normalize_vl_2 (size_t vl);
>8 │
>9 │ vfloat32m1_t
> 10
at this doesn't help chase the problem down.
I'm running reducer - will update in proper gcc channels.
Thx,
-Vineet
>
> Pan
>
> -Original Message-
> From: Vineet Gupta
> Sent: Friday, January 17, 2025 9:28 AM
> To: Andrew Waterman
> Cc: Joseph Mye
On 1/16/25 15:07, Vineet Gupta wrote:
> +CC Juzhe, Robin, gcc patches mailing list
>
> On 1/16/25 14:49, Andrew Waterman wrote:
>> On Thu, Jan 16, 2025 at 11:43 AM Vineet Gupta wrote:
>>> On 1/16/25 11:14, Joseph Myers wrote:
>>>> The simple thing to do is to c
On 1/13/25 18:08, Kito Cheng wrote:
> Thanks, that's apparently my stupid mistake...:P
No worries. We've all done that many times over !
Cheers,
-Vineet
#2.370 M/sec
| 15,403,357 branch-misses:u #0.14% of all
branches
|
| 4556.445490123 seconds time elapsed
Fixes: 46888571d242 ("RISC-V: Add cr and cf constraint")
Signed-off-by: Vineet Gupta
gcc/ChangeLog:
* config/riscv/riscv.cc
#2.370 M/sec
| 15,403,357 branch-misses:u #0.14% of all
branches
|
| 4556.445490123 seconds time elapsed
Fixes: 46888571d242 "RISC-V: Add cr and cf constraint"
Signed-off-by: Vineet Gupta
gcc/ChangeLog:
* config/riscv/riscv.cc
-authored-by: Pan Li
Signed-off-by: Vineet Gupta
PR target/117722
gcc/ChangeLog:
* config/riscv/autovec.md: Add uabd expander.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117722.c: New test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/autovec.md
On 12/20/24 17:16, Andrew Pinski wrote:
> On Fri, Dec 20, 2024 at 2:14 PM Vineet Gupta wrote:
>> This improves codegen for x264 sum of absolute difference routines.
>> The insn count is same, but we avoid double widening ops and ensuing
>> whole register moves.
>&g
variant.
Suggested-by: Robin Dapp
Co-developed-by: Pan Li
Signed-off-by: Vineet Gupta
PR target/117722
gcc/ChangeLog:
* config/riscv/autovec.md: Add uabd expander.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117722.c: New test.
Signed-off-by: Vineet Gupta
-developed-by: Pan Li
Signed-off-by: Vineet Gupta
PR target/117722
gcc/ChangeLog:
* config/riscv/autovec.md: Add uabd expander.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117722.c: New test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/autovec.md
On 12/4/24 11:52, Jonathan Wakely wrote:
>> I see you've been using the PR/nnn form for all your commits, please
>> use the [PRnnn] form as described at
>> https://gcc.gnu.org/contribute.html#patches
> Also it looks like the actual component in bugzilla is
> "rtl-optimization" not "target", so sho
On 12/4/24 11:48, Jonathan Wakely wrote:
>> gcc/ChangeLog:
>> PR target/11472
> Note that you typo'd the PR number here, so that it added a comment
> to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11472
Apologies my bad.
In my defense I ran following:
./contrib/gcc-changelog/git_check_comm
PR target/114729
* gcc.target/riscv/riscv.exp: Enable new tests to build.
* gcc.target/riscv/sched1-spills/spill1.cpp: Add new test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 4 +++
gcc/doc/invoke.texi |
bb.
* sched-rgn.cc (debug_dependencies): Dump SD_LIST_HARD_BACK deps.
Signed-off-by: Vineet Gupta
---
gcc/haifa-sched.cc | 10 +-
gcc/sched-rgn.cc | 14 --
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index cd4b6badd
On 11/6/24 14:20, Vineet Gupta wrote:
> This is broken out of predecessor promotion patch so that debugging can
> proceed during stage1 restrictions.
>
> Signed-off-by: Vineet Gupta
ping !
> ---
> gcc/haifa-sched.cc | 10 +-
> gcc/sched-rgn.cc | 14
On 11/6/24 12:11, Vineet Gupta wrote:
> changes since v1
> * Changed target hook to --param
> * squash addon patch for RISC-V opting-in, testcase here
> * updated changelog with latest perf numbers
ping !
> ---
>
> sched1 computes ECC (Excess Change Cost) for each i
This is broken out of predecessor promotion patch so that debugging can
proceed during stage1 restrictions.
Signed-off-by: Vineet Gupta
---
gcc/haifa-sched.cc | 10 +-
gcc/sched-rgn.cc | 14 --
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/gcc/haifa
dd new test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 4 +++
gcc/doc/invoke.texi | 7
gcc/haifa-sched.cc| 32 ++-
gcc/params.opt| 4 +++
gcc/testsu
On 11/4/24 16:45, Jeff Law wrote:
> On 10/31/24 1:35 PM, Vineet Gupta wrote:
>>>> An INSN can have multiple dependencies/predecessor nodes, some of them
>>>> being true dependency REG_DEP_TRUE meaning the predecessor register output
>>>> is a must have
On 10/30/24 18:11, Jeff Law wrote:
> On 10/20/24 1:40 PM, Vineet Gupta wrote:
>> Background
>> --
>> sched1 runs a preliminary "model schedular" ahead of the main list schedular.
>> Its sole purpose is to keep register pressure to mimimum [1] and
gcc.target/riscv/rvv/autovec/slp-interleave-5.c: New test.
Tested-by: Edwin Lu # Pre-commit CU #2503
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-v.cc | 6 ++--
.../riscv/rvv/autovec/slp-interleave-5.c | 35 +++
2 files changed, 38 insert
On 10/30/24 14:13, Jeff Law wrote:
> On 10/29/24 6:11 PM, Vineet Gupta wrote:
>> When bisecting for ICE in PR/117353, commit 771256bcb9dd ("RISC-V: Emit
>> costs for
>> bool and stepped const vectors") uncovered yet another latent issue (first
>> noted
Hi Richard,
Apologies as I replied w/o looking for another update on the thread first.
On 10/30/24 11:35, Richard Sandiford wrote:
I'm not saying that the algorithm gets the decision right for cactu
when tuning for in-order CPU X and running on that same CPU X.
But it seems like th
On 10/30/24 10:25, Jeff Law wrote:
> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>> That might need some finessing of the name. But I think the concept
>> is right. I'd rather base the hook (or param) on a general concept
>> like that rather than a specific "wide vs narrow" thing.
> Agreed. Na
gcc.target/riscv/rvv/autovec/slp-interleave-5.c: New test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-v.cc | 6 ++--
.../riscv/rvv/autovec/slp-interleave-5.c | 35 +++
2 files changed, 38 insertions(+), 3 deletions(-)
create mode 100644
gcc/
On 10/29/24 11:51, Wilco Dijkstra wrote:
> Hi Vineet,
>> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
> Is there evidence this change would make things significantly worse for
> some targets?
Honestly I don't think this needs to be behind any toggle or made optional at
On 10/29/24 08:05, Jeff Law wrote:
> On 10/20/24 1:40 PM, Vineet Gupta wrote:
>> Pressure senstive scheduling seems to prefer "wide" schedules with more
>> parallelism tending to more spills. This works better for in-order
>> cores [1][2].
> I'm not really s
Ping !
On 10/20/24 12:40, Vineet Gupta wrote:
> Hi,
>
> PFA patch series which improves sched1 spilling. This all started with
> SPEC2017 507.Cactu dynamic icounts on RISC-V being double than those of
> aarch64 (~2.6 trillion vs. ~1.4 trillion). Robin/Jeff hinted that the
> iss
On 10/22/24 12:02, rep.dot@gmail.com wrote:
>> +/* { dg-final { scan-assembler-times "%sfp" 0 } } */
> scan-assembler-not, please
Fixed and also in the other patch.
Thx,
-Vineet
odel_start_schedule): Call dump summary with BB reference.
* sched-rgn.cc (debug_dependencies): Print predecessors for
debugging aid.
gcc/testsuite/ChangeLog:
PR target/114729
* gcc.target/riscv/sched1-spills/hang1.c: New test.
* gcc.target/riscv/sched
(model_promote_predecessors): Add infinite
looping checks.
Signed-off-by: Vineet Gupta
---
gcc/haifa-sched.cc | 13 +
1 file changed, 13 insertions(+)
diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 67f99ce00339..471f7c686e9d 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
d1-spills/spill1.cpp: Add new test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.cc | 3 ++
gcc/testsuite/gcc.target/riscv/riscv.exp | 2 ++
.../gcc.target/riscv/sched1-spills/spill1.cpp | 31 +++
3 files changed, 36 insertions(+)
create mode
l negative baseECC to 0 only if
targetm.sched.pressure_prefer_narrow returns false.
Signed-off-by: Vineet Gupta
---
gcc/doc/tm.texi| 11 +++
gcc/doc/tm.texi.in | 2 ++
gcc/haifa-sched.cc | 30 ++
gcc/target.def | 13 +
4 files c
e backends, i.e.
+#undef TARGET_SCHED_PRESSURE_PREFER_NARROW
+#define TARGET_SCHED_PRESSURE_PREFER_NARROW hook_bool_void_true
Thx,
-Vineet
Vineet Gupta (4):
sched1: hookize pressure scheduling spilling agressiveness
RISC-V: Implement TARGET_SCHED_PRESSURE_PREFER_NARROW [PR/114729]
sche
On 8/27/24 18:10, Vineet Gupta wrote:
> On 8/7/24 10:47, Richard Sandiford wrote:
>> is probably not appropriate. We should probably just use the baseECC,
>> as suggested by the first sentence in the comment. It looks like the hack:
>>
>> diff --git a/gcc/haifa-sc
tic.
> So it still deferred to those to quite a big extent. This is almost
> certainly too conservative for out-of-order cores.
>
> So...
>
> Vineet Gupta writes:
>> On 8/5/24 21:31, Jeff Law wrote:
>>> On 8/5/24 5:35 PM, Vineet Gupta wrote:
>>>> Hi Richa
On 8/19/24 14:52, Richard Sandiford wrote:
>> 2. On RISC-V sched1 is counter intuitively assuming HARD_FP is live due to
>> the weird interaction of DF infra (which always marks HARD_FP with
>> artificial def) and ira_no_alloc_regs.
> In general, it isn't possible to predict at this stage whether
On 8/6/24 17:36, Vineet Gupta wrote:
> I'm currently pursuing a different trail which comes form observation
> that initial model setup concludes that pressure is 28 so with 27
> allocable regs we are bound to spill one.
> More on that after I find something concrete.
(caveat:
: Vineet Gupta
---
gcc/config/riscv/riscv.md | 63 +
gcc/testsuite/gcc.target/riscv/fclass.c | 38 +++
2 files changed, 101 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/fclass.c
diff --git a/gcc/config/riscv/riscv.md b/gcc/config
the expanders.
* config/riscv/riscv.md: Add UNSPEC_FCLASS.
define_insn for fclass insn.
define_expand for isfinite, isnormal, isinf.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/fclass.c: New tests.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.md
On 8/14/24 11:38, Sam James wrote:
>> Ping - looks like this is blocking the patches for builtin_isnormal and
>> builtin_isfinite !
>>
> See
> https://inbox.sourceware.org/gcc-patches/d9459db0-7301-40f6-a3cf-077017b8c...@gmail.com/.
>
> It appears to be approved.
Sorry, should have refreshed
Ping - looks like this is blocking the patches for builtin_isnormal and
builtin_isfinite !
Thx,
-Vineet
On 8/5/24 07:51, Jeff Law wrote:
>
> On 7/23/24 4:39 PM, Andrew MacLeod wrote:
>> the range is in r, and is set to [0,0]. this is the false part of what
>> is being returned for the range.
>
Hi Hao Gui,
Can you commit this soon - some of the arch patches might be waiting on this.
Thx,
-Vineet
On 8/5/24 07:59, Jeff Law wrote:
> On 7/21/24 8:10 PM, HAO CHEN GUI wrote:
>> Hi,
>>Gently ping it.
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html
> OK. Sorry for the de
Hi Raphael,
On 8/8/24 10:10, Raphael Moreira Zinsly wrote:
> From: Raphael Zinsly
>
> Improve handling of constants where its upper and lower 32-bit
> halves are the same and Zbkb is not available in riscv_move_integer.
> riscv_split_integer already handles this but the changes in
> riscv_build_i
On 8/7/24 12:28, Jeff Law wrote:
> On 8/7/24 11:47 AM, Richard Sandiford wrote:
>> I should probably start by saying that the "model" heuristic is now
>> pretty old and was originally tuned for an in-order AArch32 core.
>> The aim wasn't to *minimise* spilling, but to strike a better balance
>> bet
Hi Jeff
On 8/5/24 21:31, Jeff Law wrote:
> On 8/5/24 5:35 PM, Vineet Gupta wrote:
>> Hi Richard,
>>
>> I'm reaching out for some insight on PR/114729. Apologies in advance for
>> the long email.
>>
>> On RISC-V we are hitting sched1 pathology o
Hi Richard,
I'm reaching out for some insight on PR/114729. Apologies in advance for
the long email.
On RISC-V we are hitting sched1 pathology on SPEC2017 Cactu where
codegen spills are overwhelming the execution: disabling sched1 shaves
off 1.3 trillion dynamic icounts which is about half of tot
scv/bitmanip.md: Fix splitter.
Reported-by: Edwin Lu
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/bitmanip.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index f403ba8dbbad..d262430485e7 100644
--- a/gcc/conf
On 7/22/24 10:58, Jeff Law wrote:
> On 7/22/24 11:52 AM, Vineet Gupta wrote:
>> On 7/9/24 17:26, Jeff Law wrote:
>>> On 7/9/24 6:11 PM, Vineet Gupta wrote:
>>>> Couple weeks ago, 502.gcc was failing (PR/115669) which got fixed promptly.
>>>> On today&#x
Hi Jeff,
On 7/13/24 07:54, Vineet Gupta wrote:
> Changes since v4:
> - No functional changes.
> - Use int iterator and attr to implement expanders in md
> (inspired by loongarch patch. Thx Xi Ruoyao)
>
> Changes since v3:
> - Remove '*' from define_insn fo
gcc/testsuite/ChangeLog:
* gcc.target/riscv/fclass.c: New tests.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/iterators.md | 7 +++
gcc/config/riscv/riscv.md | 57 +
gcc/testsuite/gcc.target/riscv/fclass.c | 38 +
3 file
On 7/9/24 10:44, Edwin Lu wrote:
> Support for recognizing B as the collection of zba, zbb, zbs extensions
>
> https://github.com/riscv/riscv-b/tags
>
> V2: add b to riscv_combine_info
>
> Edwin Lu (2):
> RISC-V: Add support for B standard extension
> RISC-V: Update testsuite to use b
>
> g
_fp_classify): New helper for
the expanders.
* config/riscv/riscv.md: Add UNSPEC_FCLASS.
define_insn for fclass insn.
define_expand for isfinite, isnormal, isinf.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/fclass.c: New tests.
Signed-off-by: Vineet Gupta
--
On 7/12/24 14:52, Jeff Law wrote:
>> +(define_insn "*fclass"
>> + [(set (match_operand:X 0 "register_operand" "=r")
>> +(unspec [(match_operand:ANYF 1 "register_operand" " f")]
>> + UNSPEC_FCLASS))]
>> + "TARGET_HARD_FLOAT"
>> + "fclass.\t%0,%1";
>> + [(set_attr "type"
d UNSPEC_FCLASS.
define_insn and define_expand for fclass.
define_expand for isfinite, isnormal, isinf.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/fclass.c: New tests.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.md | 134
On 7/9/24 21:36, Jeff Law wrote:
>> +;; TODO: isinf is a bit tricky as it require trimodal return
>> +;; 1 if 0x80, -1 if 0x1, 0 otherwise
[..]
>> + rtx tmp2 = gen_reg_rtx (word_mode);
>> + emit_insn (gen_ashldi3 (tmp2, rclass, GEN_INT (w)));
>> + emit_insn (gen_lshrdi3 (tmp2, tmp2
+CC Hao Chen Gui
On 7/9/24 16:21, Jeff Law wrote:
- Don't hardcode SI in patterns, try to keep X to avoid potential
sign extension pitfalls. Implementation wise requires skipping
:MODE specifier in match_operand which is flagged as missing mode
warning.
>>> I'
On 6/30/24 06:59, Jeff Law wrote:
+;; TODO: isinf is a bit tricky as it require trimodal return
+;; 1 if 0x80, -1 if 0x1, 0 otherwise
>>> It shouldn't be terrible, but it's not trivial either.
>>>
>>> bext t0, a0, 0
>>> neg t0
>>> bext t1, a0, 7
>>> czero.nez res, t0, t1
>>> snez t1
On 7/9/24 16:23, Jeff Law wrote:
>
> On 7/9/24 5:08 PM, Vineet Gupta wrote:
>> On 7/3/24 12:08, Xi Ruoyao wrote:
>>> On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
>>>> I was also hoping to get __builtin_inf() done but unforutnately it
>>>>
On 7/3/24 21:35, Xi Ruoyao wrote:
> On Sun, 2024-06-30 at 17:47 -0700, Vineet Gupta wrote:
>> - Don't hardcode SI in patterns, try to keep X to avoid potential
>> sign extension pitfalls. Implementation wise requires skipping
>> :MODE specifier in match_o
On 7/3/24 12:08, Xi Ruoyao wrote:
> On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
>> I was also hoping to get __builtin_inf() done but unforutnately it
>> requires little more rtl foo/bar to implement a tri-modal return.
> Hmm do we really need to care the sy
On 7/1/24 06:42, Jeff Law wrote:
>>> This works because those expanders are allowed to use FAIL. Some
>>> expanders aren't allowed to do that (they're supposed to be documented
>>> appropriately in the internals manual).
>>>
>>> In the matching define_insns, you can use X and adjust their names.
>
On 7/8/24 14:03, Jeff Law wrote:
>
> On 6/30/24 6:47 PM, Vineet Gupta wrote:
>> Changes since v1:
>>- Removed UNSPEC_{INFINITE,ISNORMAL}
>>- Don't hardcode SI in patterns, try to keep X to avoid potential
>> sign extension pitfalls. Implementation w
test.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv.md | 50 +
gcc/testsuite/gcc.target/riscv/fclass.c | 18 +
2 files changed, 68 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/fclass.c
diff --git a/gcc/config/riscv/riscv.md
On 6/30/24 06:59, Jeff Law wrote:
>> Any ideas on how I can keep this and then adjust rest of patterns.
> Yea. Drop the "SImode" references from the RTL template of the
> expander. Then you'll need to verify the modes in the C fragment that
> generates code. You'd want to test the mode of
On 6/30/24 00:41, Xi Ruoyao wrote:
> On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
>> + UNSPEC_ISFINITE
>> + UNSPEC_ISNORMAL
> You don't really need them. The RTL pattern of define_expand has no use
> when you expand it via C code and DONE.
On 6/29/24 06:44, Jeff Law wrote:
>> +;; fclass instruction output bitmap
>> +;; 0 negative infinity
>> +;; 1 negative normal number.
>> +;; 2 negative subnormal number.
>> +;; 3 -0
>> +;; 4 +0
>> +;; 5 positive subnormal number.
>> +;; 6 positive normal number.
>> +;; 7 positive in
1 - 100 of 360 matches
Mail list logo
