d 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 Fri, Mar 25
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 ima
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 iss
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. Thi
+ p->i
+ p->j;
}
> On 17 Aug 2017, at 10:29 AM, Michael Clark 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
> know the structure is aligned a
> On 17 Aug 2017, at 10:41 AM, Andrew Pinski wrote:
>
> On Wed, Aug 16, 2017 at 3:29 PM, Michael Clark 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
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
> On 18 Aug 2017, at 10:41 AM, Andrew Pinski wrote:
>
> On Thu, Aug 17, 2017 at 3:29 PM, Michael Clark wrote:
>> Sorry I had to send again as my Apple mailer is munging emails. I’ve
>> disabled RTF.
>>
>>
>> This one is quite interesting:
>>
> On 18 Aug 2017, at 11:13 AM, Michael Clark 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
Getting my 3’s and 5’s swapped. Confuse
> On 18 Aug 2017, at 10:41 PM, Gabriel Paubert 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 is quite interesti
> On 18 Aug 2017, at 10:56 PM, Michael Clark wrote:
>
>>
>> On 18 Aug 2017, at 10:41 PM, Gabriel Paubert 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’v
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 using
> On 26 Aug 2017, at 8:39 PM, Andrew Pinski wrote:
>
> On Sat, Aug 26, 2017 at 1:23 AM, Michael Clark wrote:
>> 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. O
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 wrote:
>
>>
>> On 26 Aug 2017, at 8:39 PM, Andrew Pinski wrote:
>>
>> On Sat, Aug 26, 2017 at
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 following:
> On 30 Aug 2017, at 12:36 PM, Michael Clark 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 to state that riscv is
>
> On 30 Aug 2017, at 9:14 PM, Richard Biener wrote:
>
> On Wed, Aug 30, 2017 at 2:36 AM, Michael Clark wrote:
>> Dear GCC folk,
>>
>>
>> # Issue Background
>>
>> We’re investigating an issue with redundant sign-extension instructions
>> be
> On 30 Aug 2017, at 9:43 PM, Michael Clark 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
>>> @@ -1503,6 +1503,10 @@ simplify_unary
> On 31 Aug 2017, at 7:20 AM, Matthew Fortune
> wrote:
>
> Jeff Law writes:
>> On 08/30/2017 06:52 AM, Richard Biener wrote:
>>> On Wed, Aug 30, 2017 at 11:53 AM, Michael Clark
>>> wrote:
>>>>
>>>>> On 30 Aug 2017, at 9:43 PM,
> On 31 Aug 2017, at 2:12 PM, Michael Clark wrote:
>
>>
>> On 31 Aug 2017, at 7:20 AM, Matthew Fortune
>> wrote:
>>
>> Jeff Law writes:
>>> On 08/30/2017 06:52 AM, Richard Biener wrote:
>>>> On Wed, Aug 30, 2017 at 11:53 AM, Michael
> On 19 Aug 2017, at 4:10 AM, Richard Henderson 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
>>sar edi, 27
>>m
> 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 conservative. As a resul
> On 13 Sep 2017, at 12:47 PM, Segher Boessenkool
> 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 repeatedly) which GCC could/should do
> On 13 Sep 2017, at 1:15 PM, Michael Clark 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 -O3 on x86-64
> -Os s
> On 5 Sep 2017, at 9:35 AM, Michael Clark wrote:
>
>>
>> On 19 Aug 2017, at 4:10 AM, Richard Henderson wrote:
>>
>> On 08/17/2017 03:29 PM, Michael Clark wrote:
>>> hand coded x86 asm (no worse because the sar depends on the lea)
>>>
>&
> On 14 Sep 2017, at 3:06 AM, Allan Sandfeld Jensen wrote:
>
> On Dienstag, 12. September 2017 23:27:22 CEST Michael Clark wrote:
>>> On 13 Sep 2017, at 1:57 AM, Wilco Dijkstra wrote:
>>>
>>> Hi all,
>>>
>>> At the GNU Cauldron I was ins
> 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
>> (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00472.html)
>> rebased on r249469. The m
> On 16 Sep 2017, at 8:59 AM, Segher Boessenkool
> 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
>> subregisters. I did an experiment on RISC-V t
the current version of the port.
Michael.
> On 30 Aug 2017, at 12:36 PM, Michael Clark wrote:
>
> Dear GCC folk,
>
>
> # Issue Background
>
> We’re investigating an issue with redundant sign-extension instructions being
> emitted with the riscv backend. Firstly I wou
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
> 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.
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 r
> 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 i
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
multi-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
Hi Folks,
*sending again with Thunderbird because Apple Mail munged the message*.
I wanted to share a seed of an idea I have been ruminating on for a
while, and that is being able to return alloca memory from a function.
I think it’s trivially possible by hacking the epilogue to unlink the
f
On 8/15/24 06:24, Michael Clark wrote:
Hi Folks,
*sending again with Thunderbird because Apple Mail munged the message*.
I wanted to share a seed of an idea I have been ruminating on for a
while, and that is being able to return alloca memory from a function.
I think it’s trivially possible
On 8/23/24 15:24, Michael Clark wrote:
On 8/15/24 06:24, Michael Clark wrote:
Hi Folks,
like I said this is crazy talk as alloca isn't even in the C standard.
but VLAs are, and the current implementation of VLAs depends on alloca.
one more thing. it doesn't require PT_GNU_STACK o
On 8/23/24 15:46, Michael Clark wrote:
one more thing. it doesn't require PT_GNU_STACK or writable stacks like
GCC nested functions. 🙂 so I think it is safer but it does have safety
issues, mostly related to stack overflows but its going to need some
careful analysis with respect t
On 8/23/24 15:57, Michael Clark wrote:
On 8/23/24 15:46, Michael Clark wrote:
one more thing. it doesn't require PT_GNU_STACK or writable stacks
like GCC nested functions. 🙂 so I think it is safer but it does have
safety issues, mostly related to stack overflows but its going to need
I like the sound of resolved path identity from search, including the
constructed full path and the index within include paths. if I was writing a
compiler from scratch, i'd problem do something like this:
SHA2(include-path-search-offset-integer-of-found-header-to-support-include-next)
+
SHA2
> On 17 Dec 2024, at 5:44 AM, Alexander Monakov wrote:
>
>
>> On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
>>
>> I would like to provide a facility to create wrapper functions without
>> lots of argument shuffling. To achieve that, the wrapping function and
>> the wrapped function sho
Hi Folks,
here is an idea expressed as a simple proof-of-concept simulator.
- https://github.com/michaeljclark/glyph/
I have been working on a proof-of-concept simulator for a RISC
architecture with an immediate base register next to the program counter
to split the front-end stream into inde
43 matches
Mail list logo
