Hi,
I have the following test case (reduced from Linux kernel sources) and it seems
gcc is optimizing away the first loop iteration.
arc-linux-gcc -c -O2 star-9000857057.c -fno-branch-count-reg --save-temps -mA7
--->8-
static inline int __test_bit(unsigned int nr, const volat
On Friday 03 July 2015 07:15 PM, Richard Biener wrote:
> On Fri, Jul 3, 2015 at 3:10 PM, Vineet Gupta
> wrote:
>> Hi,
>>
>> I have the following test case (reduced from Linux kernel sources) and it
>> seems
>> gcc is optimizing away the first loop iterat
On Monday 06 July 2015 12:04 PM, Richard Biener wrote:
>> The point being ARC ISA provides a neat feature where core only considers
>> lower 5
>> > bits of bitpos operands. Thus we can make such behaviour not only
>> > deterministic in
>> > the context of ARC, but also optimal, eliding the need f
Hi,
ARC Linux has an in-kernel dwarf unwinder which has historically consumed
.debug_frame. The kernel is built with -gdwarf-2 and
-fasynchronous-unwind-tables
toggles which until recently used to generate both .debug_frame and .eh_frame -
latter being discarded by the kernel linker script.
With
On Thursday 16 June 2016 09:44 PM, Vineet Gupta wrote:
> Hi,
>
> ARC Linux has an in-kernel dwarf unwinder which has historically consumed
> .debug_frame. The kernel is built with -gdwarf-2 and
> -fasynchronous-unwind-tables
> toggles which until recently used to generate bot
Hi,
On 9/16/22 00:47, Jan Hubicka via Gcc wrote:
Hello,
Hello,
We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on September 16-18, 2022. We are looking forward
to meet you again after three years!
As for the previous instances, we have setup a wiki page
On 9/28/22 10:03, Vineet Gupta wrote:
We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on September 16-18, 2022. We are looking forward
to meet you again after three years!
As for the previous instances, we have setup a wiki page for
details:
https
Hi,
I have a testcase (from real workloads) involving C++ atomics and trying
to understand the codegen (gcc 12) for RVWMO and x86.
It does mix atomics with non-atomics so not obvious what the behavior is
intended to be hence some explicit CC of subject matter experts
(apologies for that in adv
I suggested in the document I posted to the list.
Hans
On Thu, Oct 13, 2022 at 12:31 PM Vineet Gupta
wrote:
Hi,
I have a testcase (from real workloads) involving C++ atomics and
trying
to understand the codegen (gcc 12) for RVWMO and x86.
It does mix atomics with non-ato
On 10/13/22 13:30, Uros Bizjak wrote:
OTOH, for x86 (same default toggles) there's no barriers at all.
_Z10bar_seqcstiPi:
endbr64
movlg(%rip), %eax
movl%eax, (%rsi)
movla(%rip), %eax
addl%edi, %eax
ret
Regardin
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
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/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
Hi Jakub,
I had a question about the aforementioned commit in RV backend.
(define_split
[(set (match_operand:GPR 0 "register_operand")
(and:GPR (match_operand:GPR 1 "register_operand")
(match_operand:GPR 2 "p2m1_shift_operand")))
+ (clobber (match_operand:GPR 3 "regist
On 11/4/22 16:13, Jeff Law wrote:
On 11/4/22 16:59, Vineet Gupta wrote:
Hi Jakub,
I had a question about the aforementioned commit in RV backend.
(define_split
[(set (match_operand:GPR 0 "register_operand")
(and:GPR (match_operand:GPR 1 "r
Hi,
I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
Problem also happens with -O3 -ffast-math (and goes away with fast-math
removed)
I've bisected it to b7fd7fb50111 ("frange: drop endpoints to min/max
representable nu
On 2/2/23 15:38, Vineet Gupta wrote:
Hi,
I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
Problem also happens with -O3 -ffast-math (and goes away with
fast-math removed)
I've bisected it to b7fd7fb5011
On 2/2/23 23:36, Richard Biener wrote:
There's a CLOSED INVALID bug in bugzilla
about the povray failure as well.
Thx for the pointer ! For the record it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
> The question is what to do with 511.povray_r as we want to support
SPECs with -O
Hi Jeff, Kito,
I need some ideas to proceed with PR/109279: pertaining to longer term
direction and short term fix.
First the executive summary:
long long f(void)
{
return 0x0101010101010101ull;
}
Up until gcc 12 this used to generate const pool type access.
lui a5,%hi(.LANCHOR0)
Hi Jeff,
I finally got around to collecting various observations on PR/109279 -
more importantly the state of large constants in RV backend, apologies
in advance for the long email.
It seems the various commits in area have improved the original test
case of 0x1010101_01010101
Before 2e8
Hi Jeff,
Thx for the detailed explanation and insight.
On 6/7/23 16:44, Jeff Law wrote:
With 2e886eef7f2b, define_insn_and_split "*mvconst_internal" recog()
kicks in during cse1, eliding insns for a const_int.
(insn 7 6 8 2 (set (reg:DI 137)
(const_int [0x1010101])) {*mvconst_int
Hi Jeff, Robin,
This morning I was talking about the following test where subreg
promoted is not being generated during expand, whereas for RISC-V
ABI/ISA it should.
gcc.c-torture/compile/20070121.c -Os -march=rv64gc -mabi=lp64d
expand_gimple_basic_block
expand_gimple_stmt
...
ex
Hi,
I had a question about interpretation of FDE's CIE_pointer field (for
.debug_frame)
The spec say (from dwarf4 version although it really doesn't matter):
"2. CIE_pointer (4 or 8 bytes, see Section 7.4)
A constant offset into the .debug_frame section that denotes the CIE that is
associated w
On 06/24/2013 12:33 PM, Jakub Jelinek wrote:
> On Mon, Jun 24, 2013 at 12:06:27PM +0530, Vineet Gupta wrote:
>> I had a question about interpretation of FDE's CIE_pointer field (for
>> .debug_frame)
>>
>> The spec say (from dwarf4 version although it really doesn&
On 06/24/2013 12:58 PM, Jakub Jelinek wrote:
> On most targets, .debug_* sections are placed at address 0, so absolute
> relocations are the same as relocations relative to the start of the
> section.
> [snipped]
>
> So, either .debug_* sections are placed at address 0 and then absolute
> relocatio
On 06/25/2013 12:35 AM, Richard Henderson wrote:
> On 06/24/2013 12:37 AM, Vineet Gupta wrote:
>> Aha, I see what's happening. For historical reasons, ARC Linux kernel stack
>> unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being
>> non
>>
26 matches
Mail list logo
