On 10/19/22 01:46, Richard Biener wrote:
On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc wrote:
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a ch
On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc wrote:
>
>
> On 10/18/22 20:09, Vineet Gupta wrote:
> >
> > On 10/18/22 16:36, Jeff Law wrote:
> There isn't a great place in GCC to handle this right now. If the
> constraints were relaxed in PRE, then we'd have a chance, but
> gett
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but
getting the cost model right is going to be tough.
It would have been better (for this
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but
getting the cost model right is going to be tough.
It would have been better (for this specific case) if loop unrolling
was not
On 10/18/22 15:51, Vineet Gupta wrote:
Where BB4 corresponds to .L2 and BB6 corresponds to .L3. Evaluation
of the constants occurs in BB3 and BB5.
And Evaluation here means use of the constant (vs. definition ?).
In this case, use of the constant.
PRE/GCSE is better suited for this
Hi Jeff,
On 10/14/22 09:54, Jeff Law via Gcc wrote:
...
.L2:
xor a4,a4,a5
andi a4,a4,1
srli a3,a0,2
srli a5,a5,1
beq a4,zero,.L3
li a4,-24576 # 0x_A000
addi a4,a4,1 # 0x_A001
xor a5,a5,a4
zext.h a5,a5
.L3:
xo
On 10/14/22 09:56, Vineet Gupta wrote:
Hi,
When analyzing coremark build for RISC-V, noticed redundant constants
not being eliminated. While this is a recurrent issue with RV, this
specific instance is not unique to RV as I can trigger similar output
on aarch64 with -fno-if-conversion, henc
Hi,
When analyzing coremark build for RISC-V, noticed redundant constants
not being eliminated. While this is a recurrent issue with RV, this
specific instance is not unique to RV as I can trigger similar output on
aarch64 with -fno-if-conversion, hence something which could be
addressed in c
