https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
--- Comment #1 from Vineet Gupta ---
Fix posted here
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613106.html
Essentially:
case PLUS:
if (TARGET_ZBA
&& mode == word_mode
&& GET_CODE (XEXP (x, 0)) == MULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
Bug ID: 108987
Summary: [13 Regression] RISC-V: shiftadd cost model bug
needlessly preferring syth_multiply
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #23 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #20)
> Yea, I think so (3 shifts). Two for masking, one to put the bits in the
> right position. Then we just have to figure out how to combine the initial
> shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #22 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #21)
> However
> try_combine
> recog_for_combine
> recog_for_combine_1
> recog( )
>
> is failing and we get "Failed to recognize..."
False alar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #21 from Vineet Gupta ---
I've been experimenting with
(define_predicate "consecutive_bits_operand"
(match_code "const_int")
{
unsigned HOST_WIDE_INT val = UINTVAL (op);
if (exact_log2 ((val >> ctz_hwi (val)) + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #19 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #13)
> Trying 7, 8, 9 -> 10:
> 7: r140:DI=0x1
> 8: r141:DI=r140:DI<<0x26
> REG_DEAD r140:DI
> REG_EQUAL 0x40
> 9: r139:DI=r141:DI-0x40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #18 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #17)
> Vineet: I don't know your priorities and such, but I've got a junior
> engineer starting in a bit under two weeks and this would actually be a good
> issue for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #14 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #13)
> Trying 7, 8, 9 -> 10:
> 7: r140:DI=0x1
> 8: r141:DI=r140:DI<<0x26
> REG_DEAD r140:DI
> REG_EQUAL 0x40
> 9: r139:DI=r141:DI-0x40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #11 from Vineet Gupta ---
This definitely seems worth pursuing:
For bitmanip, following four insn seq matches
Trying 7, 8, 6 -> 9:
7: r78:DI=0x40
8: r77:DI=r78:DI-0x40
REG_EQUAL 0x3fffc0
6: r76:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #10 from Vineet Gupta ---
At expand time, RV backend was NOT creating REQ_EQUAL note for 1 << 38
(insn 8 7 9 2 (set (reg:DI 79)
(ashift:DI (reg:DI 78)
(const_int 38 [0x26]))) "../../../shifter.c":10:40 -1
Howe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #9 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #7)
> There's some code in combine that's supposed to take advantage of REG_EQUAL
> notes which is supposed to help with this kind of scenario. Digging into
> that mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #6 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Vineet Gupta from comment #3)
> > Interestingly, if one builds for -march=rv64gc_zbs # single bit extension
> >
> > then the optimal code seq for b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #5 from Vineet Gupta ---
Gimple for the test is
_1 = a_2(D) << 6;
_3 = _1 & 274877906880; // 0x3f__ffc0
And 0x3f__ffc0 = 0x40__ - 0x40
For !TARGET_ZBA there's a combiner pattern to match the seq of instructi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Vineet Gupta changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
--- Comment #9 from Vineet Gupta ---
> > Can this be back-ported to gcc 12 please ?
>
> Do you have an indication that this is a regression?
No, but this does seem like a bug, aren't those backported ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
--- Comment #7 from Vineet Gupta ---
Can this be back-ported to gcc 12 please ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #2 from Vineet Gupta ---
Yes I noted that in the original report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Bug ID: 106602
Summary: riscv: suboptimal codegen for shift left, right, left
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at rivosinc dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
--- Comment #3 from Vineet Gupta ---
FWIW this was seen with riscv64 build of gcc, but same tree behavior seen with
aarch64 gcc 12.1.
For single copy-loop src, final output is inline copy loop
-->8--
[local count: 1063004409]:
# j_131 = P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
--- Comment #2 from Vineet Gupta ---
Original stream benchmark [1] at https://github.com/jeffhammond/STREAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at rivosinc dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
Bug ID: 106533
Summary: loop distribution not distributing inner loop (to
memcpy) when perfect loop nest
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severit
24 matches
Mail list logo
