Spurious register spill with volatile function argument

; > It would be good to figure out how to get rid of the spurious register spills. > > The strength reduction optimization isn't always profitable on Rocket, > as it increases instruction count and code size. The divider has an > early out and for small numbers is quite fast. > > On Fr

x86 branches vs conditional moves

Hi, Curious about this codegen: - https://godbolt.org/g/5XxP5S Why does gcc branch on _Bool, but emits a conditional move for an integer? can it emit cmovne instead of branching? also curious where one would change this to learn about GCC internals. It’s not a bug, but it is a performance

Re: Bit-field struct member sign extension pattern results in redundant

> On 18 Aug 2017, at 11:13 AM, Michael Clark <michaeljcl...@mac.com> wrote: > > So it is a bug on arm too? and can be done with one sbfiz instruction? > (assuming I’m understand sbfiz from my first reading) e.g. > > sbfiz w0, w0, 0, 2 >ret Get

Bit-field struct member sign extension pattern results in redundant

Sorry I had to send again as my Apple mailer is munging emails. I’ve disabled RTF. This one is quite interesting: - https://cx.rv8.io/g/WXWMTG It’s another target independent bug. x86 is using some LEA followed by SAR trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice. In any case

Re: Bit-field struct member sign extension pattern results in redundant

> On 18 Aug 2017, at 10:41 AM, Andrew Pinski <pins...@gmail.com> wrote: > > On Thu, Aug 17, 2017 at 3:29 PM, Michael Clark <michaeljcl...@mac.com> wrote: >> Sorry I had to send again as my Apple mailer is munging emails. I’ve >> disabled RTF. >>

Re: Redundant loads for bitfield accesses

+ p->i + p->j; } > On 17 Aug 2017, at 10:29 AM, Michael Clark <michaeljcl...@mac.com> wrote: > > Hi, > > Is there any reason for 3 loads being issued for these bitfield accesses, > given two of the loads are bytes, and one is a half; the compiler appears to > kno

Redundant loads for bitfield accesses

Hi, Is there any reason for 3 loads being issued for these bitfield accesses, given two of the loads are bytes, and one is a half; the compiler appears to know the structure is aligned at a half word boundary. Secondly, the riscv code is using a mixture of 32-bit and 64-bit adds and shifts.

Re: Redundant loads for bitfield accesses

> On 17 Aug 2017, at 10:41 AM, Andrew Pinski <pins...@gmail.com> wrote: > > On Wed, Aug 16, 2017 at 3:29 PM, Michael Clark <michaeljcl...@mac.com> wrote: >> Hi, >> >> Is there any reason for 3 loads being issued for these bitfield accesses, >&

Re: Bit-field struct member sign extension pattern results in redundant

> On 18 Aug 2017, at 10:41 PM, Gabriel Paubert <paub...@iram.es> wrote: > > On Fri, Aug 18, 2017 at 10:29:04AM +1200, Michael Clark wrote: >> Sorry I had to send again as my Apple mailer is munging emails. I’ve >> disabled RTF. >> >> >> This one

Re: Bit-field struct member sign extension pattern results in redundant

> On 18 Aug 2017, at 10:56 PM, Michael Clark <michaeljcl...@mac.com> wrote: > >> >> On 18 Aug 2017, at 10:41 PM, Gabriel Paubert <paub...@iram.es> wrote: >> >> On Fri, Aug 18, 2017 at 10:29:04AM +1200, Michael Clark wrote: >>> Sorry I had

Re: RFC: Improving GCC8 default option settings

> On 14 Sep 2017, at 3:06 AM, Allan Sandfeld Jensen <li...@carewolf.com> wrote: > > On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote: >>> On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra <wilco.dijks...@arm.com> wrote: >>> >>> Hi

Re: Redundant sign-extension instructions on RISC-V

the current version of the port. Michael. > On 30 Aug 2017, at 12:36 PM, Michael Clark <michaeljcl...@mac.com> wrote: > > Dear GCC folk, > > > # Issue Background > > We’re investigating an issue with redundant sign-extension instructions being > emitted with t

Re: [RFC] type promotion pass

> On 16 Sep 2017, at 8:59 AM, Segher Boessenkool <seg...@kernel.crashing.org> > wrote: > > Hi! > > On Sat, Sep 16, 2017 at 08:47:03AM +1200, Michael Clark wrote: >> RISC-V defines promote_mode on RV64 to promote SImode to signed DImode >> subregis

Re: [RFC] type promotion pass

> On 16 Sep 2017, at 1:04 AM, David Edelsohn wrote: > > On Tue, Sep 5, 2017 at 5:26 AM, Prathamesh Kulkarni > wrote: >> Hi, >> I have attached revamped version of Kugan's original patch for type promotion >>

Re: Bit-field struct member sign extension pattern results in redundant

> On 5 Sep 2017, at 9:35 AM, Michael Clark <michaeljcl...@mac.com> wrote: > >> >> On 19 Aug 2017, at 4:10 AM, Richard Henderson <r...@twiddle.net> wrote: >> >> On 08/17/2017 03:29 PM, Michael Clark wrote: >>> hand coded x86 asm (no worse becau

Re: Redundant sign-extension instructions on RISC-V

> On 30 Aug 2017, at 12:36 PM, Michael Clark <michaeljcl...@mac.com> wrote: > > Dear GCC folk, > > > # Issue Background > > We’re investigating an issue with redundant sign-extension instructions being > emitted with the riscv backend. Firstly I would like t

Re: Redundant sign-extension instructions on RISC-V

> On 30 Aug 2017, at 9:43 PM, Michael Clark <michaeljcl...@mac.com> wrote: > >>> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c >>> index ce632ae..25dd70f 100644 >>> --- a/gcc/simplify-rtx.c >>> +++ b/gcc/simplify-rtx.c >>> @@ -150

Re: Redundant sign-extension instructions on RISC-V

> On 30 Aug 2017, at 9:14 PM, Richard Biener <richard.guent...@gmail.com> wrote: > > On Wed, Aug 30, 2017 at 2:36 AM, Michael Clark <michaeljcl...@mac.com> wrote: >> Dear GCC folk, >> >> >> # Issue Background >> >> We’re investig

Re: RFC: Improving GCC8 default option settings

> On 13 Sep 2017, at 1:15 PM, Michael Clark <michaeljcl...@mac.com> wrote: > > - https://rv8.io/bench#optimisation > - https://rv8.io/bench#executable-file-sizes > > -O2 is 98% perf of -O3 on x86-64 > -Os is 81% perf of -O3 on x86-64 > > -O2 saves 5% space on -

Re: RFC: Improving GCC8 default option settings

> On 13 Sep 2017, at 12:47 PM, Segher Boessenkool <seg...@kernel.crashing.org> > wrote: > > On Wed, Sep 13, 2017 at 09:27:22AM +1200, Michael Clark wrote: >>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was >>> mentioned repeatedl

Re: RFC: Improving GCC8 default option settings

> On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote: > > Hi all, > > At the GNU Cauldron I was inspired by several interesting talks about > improving > GCC in various ways. While GCC has many great optimizations, a common theme is > that its default settings are rather

Quantitative analysis of -Os vs -O3

Dear GCC folk, I have to say that’s GCC’s -Os caught me by surprise after several years using Apple GCC and more recently LLVM/Clang in Xcode. Over the last year and a half I have been working on RISC-V development and have been exclusively using GCC for RISC-V builds, and initially I was

Re: Quantitative analysis of -Os vs -O3

> On 26 Aug 2017, at 8:39 PM, Andrew Pinski <pins...@gmail.com> wrote: > > On Sat, Aug 26, 2017 at 1:23 AM, Michael Clark <michaeljcl...@mac.com> wrote: >> Dear GCC folk, >> I have to say that’s GCC’s -Os caught me by surprise after several years >> using

Re: Quantitative analysis of -Os vs -O3

but the performance increase is considerably more. I could perhaps show ratios of performance vs size between -O2 and -Os. > On 26 Aug 2017, at 10:05 PM, Michael Clark <michaeljcl...@mac.com> wrote: > >> >> On 26 Aug 2017, at 8:39 PM, Andrew Pinski <pins...@gmail.com>

Re: Bit-field struct member sign extension pattern results in redundant

> On 19 Aug 2017, at 4:10 AM, Richard Henderson <r...@twiddle.net> wrote: > > On 08/17/2017 03:29 PM, Michael Clark wrote: >> hand coded x86 asm (no worse because the sar depends on the lea) >> >> sx5(int): >>shl edi, 27 >>

Redundant sign-extension instructions on RISC-V

Dear GCC folk, # Issue Background We’re investigating an issue with redundant sign-extension instructions being emitted with the riscv backend. Firstly I would like to state that riscv is possibly a unique backend with respect to its canonical sign-extended register form due to the

Re: Redundant sign-extension instructions on RISC-V

> On 31 Aug 2017, at 7:20 AM, Matthew Fortune <matthew.fort...@imgtec.com> > wrote: > > Jeff Law <l...@redhat.com> writes: >> On 08/30/2017 06:52 AM, Richard Biener wrote: >>> On Wed, Aug 30, 2017 at 11:53 AM, Michael Clark <michaeljcl...@mac.com> &

Re: Redundant sign-extension instructions on RISC-V

> On 31 Aug 2017, at 2:12 PM, Michael Clark <michaeljcl...@mac.com> wrote: > >> >> On 31 Aug 2017, at 7:20 AM, Matthew Fortune <matthew.fort...@imgtec.com> >> wrote: >> >> Jeff Law <l...@redhat.com> writes: >>> On 08/30/2017 06:

Re: Register Allocation Graph Coloring algorithm and Others

translator Michael Clark, Bruce Hoult https://carrv.github.io/papers/clark-rv8-carrv2017.pdf Our JIT already performs almost twice as fast a QEMU and we are using a static register allocation, and QEMU i believe has a register allocator. We are mapping a 31 register RISC architecture

Re: RISC-V ELF multilibs

> On 1/06/2018, at 6:16 PM, Sebastian Huber > wrote: > > On 29/05/18 20:02, Jim Wilson wrote: >>> Most variants include the C extension. Would it be possible to add >>> -march=rv32g and -march=rv64g variants? >> >> The expectation is that most implementations will include the C extension.

Re: That light at the end of the tunnel?

> On 31/07/2018, at 12:47 AM, Eric S. Raymond wrote: > > Richard Biener : >> Ok, so let me ask whether you can currently convert trunk and >> gcc-{6,7,8}-branch >> successfully, ignoring "merges" into them (shouldn't have happened). All >> other >> branches can in theory be converted later

Re: [RFC] Adding Python as a possible language and it's usage

On 20/07/2018, at 4:12 AM, Richard Earnshaw (lists) mailto:richard.earns...@arm.com>> wrote: > On 19/07/18 12:30, Florian Weimer wrote: >> * Segher Boessenkool: >> >>> What would the advantage of using Python be? I haven't heard any yet. >>> Awk may be a bit clunky but at least it is easily

Re: coding question

Hi Cesar, > On 12/12/2018, at 10:31 AM, Moreno, Cesar A wrote: > > > > HOW do Imalloc or newan array of complex numbers in GNU C++ code ? > MALLOC does not work, how do I use MALLOC correctly or NEW ? > > I made a struct called complex (for a complex number with realp and

Re: [RFC] zip_vector: in-memory block compression of integer arrays

On 17/08/22 7:10 pm, Richard Biener wrote: Q. Why is it specifically of interest to GCC developers? I think the best way to answer this is with questions. How can we model a block-based iterator for a sparse array that is amenable to vectorization? There are aspects to the zip_vector iterator

[RFC] zip_vector: in-memory block compression of integer arrays

Hi Folks, This is an edited version of a message posted on the LLVM Discourse. I want to share what I have been working on as I feel it may be of interest to the GCC compiler developers, specifically concerning alias analysis and optimizations for iteration of sparse block-based