https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #29 from CVS Commits ---
The releases/gcc-13 branch has been updated by Palmer Dabbelt
:
https://gcc.gnu.org/g:a252c73b1f2b920d8a2ff2e8ca59989e06652fbb
commit r13-7220-ga252c73b1f2b920d8a2ff2e8ca59989e06652fbb
Author: Palmer Dabbel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #28 from CVS Commits ---
The trunk branch has been updated by Palmer Dabbelt :
https://gcc.gnu.org/g:8c010f6fe5ebe80d2e054b31e04ae0e9f12ae368
commit r14-5-g8c010f6fe5ebe80d2e054b31e04ae0e9f12ae368
Author: Palmer Dabbelt
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #26 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:2e886eef7f2b5aadb00171af868f0895b647c3a4
commit r13-4907-g2e886eef7f2b5aadb00171af868f0895b647c3a4
Author: Raphael Moreira Zinsly
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #25 from Jeffrey A. Law ---
To outline what we were thinking. Yes, it's possible that 4->3 combinations
aren't supported. I'd have to sit down with the combine sources to be sure.
So the alternate approach we came up with was to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #24 from Jeffrey A. Law ---
Just a note. Raphael and I are going to poke at this from a different
direction.
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 #20 from Jeffrey A. Law ---
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
with the 3 for the masking and ultimately result w
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 #17 from Jeffrey A. Law ---
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
them to tackle as part of learning about GCC. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #16 from Andrew Pinski ---
(In reply to Vineet Gupta from comment #14)
> (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
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #15 from Jeffrey A. Law ---
THe hope is the shift 6 combines with the first shift you emit for
(set (reg:DI 137)
(and:DI (reg:DI 138)
(const_int 274877906880 [0x3fffc0])))
Conceptually this is similar to creating br
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 #13 from Jeffrey A. Law ---
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
REG_DEAD r141:DI
REG_EQUAL 0x3fffc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #12 from Jeffrey A. Law ---
But insns 6, 7 and 8 aren't important here. We have a REG_EQUAL on insn 9
which indicates that (reg:DI 77) has the value 0xffc0. So I would
have expected combine to substitute that into the u
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
palmer at gcc dot gnu.org changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #7
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
--- Comment #4 from Andrew Pinski ---
(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 bitmanip is generated, while no zbs
> instructions a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Vineet Gupta changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com,
29 matches
Mail list logo
