On Fri, May 29, 2015 at 12:41 PM, Pritam Gharat
wrote:
> GCC builds a chain of recurrence to capture a pattern in which an
> array is accessed in a loop. Is there any function which identifies
> that gcc has built a chain of recurrence? Is this information
> associated to the gimple assignment whi
GCC builds a chain of recurrence to capture a pattern in which an
array is accessed in a loop. Is there any function which identifies
that gcc has built a chain of recurrence? Is this information
associated to the gimple assignment which accesses the array elements?
Thanks,
Pritam Gharat
On Thu, May 28, 2015 at 02:42:22PM -0500, Segher Boessenkool wrote:
> > That record form andi. is slower on many processors,
>
> Is it? On which processors?
That sort of info is in the IBM confidential processor book4
supplements. So I can't tell you. (I think it is completely crazy to
keep in
I tried compiling the following code with -mmcu=attiny13a -Os -flto
using 4.8 and 5.1:
#define NOT_A_REG 0
#define digitalPinToPortReg(PIN) \
( ((PIN) >= 0 && (PIN) <= 7) ? &PORTB : NOT_A_REG)
#define digitalPinToBit(P) ((P) & 7)
#define HIGH 1
#define LOW 0
inline void digitalWrite(int
On 05/28/2015 01:39 AM, Maxim Kuvyrkov wrote:
> Hi,
>
> Akashi-san and I have been discussing required GCC changes to make kernel's
> livepatching work for AArch64 and other architectures. At the moment
> livepatching is supported for x86[_64] using the following options: "-pg
> -mfentry -mrec
Snapshot gcc-4.8-20150528 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150528/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, May 28, 2015 at 09:40:57PM +0200, Jakub Jelinek wrote:
> On Thu, May 28, 2015 at 03:29:02PM -0400, Rich Felker wrote:
> > > You're not missing anything. But do you want the performance of a
> > > library to depend on how the main executable is compiled?
> >
> > Not directly. But I'd rathe
On Fri, May 29, 2015 at 12:09:42AM +0930, Alan Modra wrote:
> It's really annoying when you fix a combine bug and get worse code..
Heh. You've been on the receiving end of that a lot lately :-/
> void foo (signed char *p) { if (*p != 0) *p = 1; }
>
> before after
> foo:
On Thu, May 28, 2015 at 03:29:02PM -0400, Rich Felker wrote:
> > You're not missing anything. But do you want the performance of a
> > library to depend on how the main executable is compiled?
>
> Not directly. But I'd rather be in that situation than have
> pessimizations in library codegen to a
On Thu, May 28, 2015 at 11:41:10AM -0700, Richard Henderson wrote:
> On 05/28/2015 10:59 AM, Rich Felker wrote:
> >Am I missing something?
>
> You're not missing anything. But do you want the performance of a
> library to depend on how the main executable is compiled?
Not directly. But I'd rathe
On 05/28/2015 10:59 AM, Rich Felker wrote:
Am I missing something?
You're not missing anything. But do you want the performance of a library to
depend on how the main executable is compiled?
r~
> Our proposal is that instead of adding -mfentry/-mnop-count/-mrecord-mcount
> options to other architectures, we should implement a target-independent
> option -fprolog-pad=N, which will generate a pad of N nops at the beginning
> of each function and add a section entry describing the pad sim
On Thu, May 28, 2015 at 08:29:31AM -0700, Richard Henderson wrote:
> On 05/28/2015 04:27 AM, H.J. Lu wrote:
> > You get consecutive jmpq's because x86 PLT entry is used as the
> > canonical function address. If you compile main with -fno-plt -fPIE, you
> > get:
>
> Well, duh. If the main executa
On Thu, May 28, 2015 at 11:13 AM, Alan Modra wrote:
> On Thu, May 28, 2015 at 10:47:53AM -0400, David Edelsohn wrote:
>> This seems like a problem with the cost model. Rc instructions are
>> more expensive and should be represented as such in rtx_costs.
>
> The record instructions do have a highe
On Thu, May 28, 2015 at 9:02 AM, Jakub Jelinek wrote:
> On Thu, May 28, 2015 at 08:52:28AM -0700, Richard Henderson wrote:
>> On 05/28/2015 08:42 AM, H.J. Lu wrote:
>> > On Thu, May 28, 2015 at 8:29 AM, Richard Henderson wrote:
>> >> On 05/28/2015 04:27 AM, H.J. Lu wrote:
>> >>> You get consecuti
On Thu, May 28, 2015 at 08:52:28AM -0700, Richard Henderson wrote:
> On 05/28/2015 08:42 AM, H.J. Lu wrote:
> > On Thu, May 28, 2015 at 8:29 AM, Richard Henderson wrote:
> >> On 05/28/2015 04:27 AM, H.J. Lu wrote:
> >>> You get consecutive jmpq's because x86 PLT entry is used as the
> >>> canonica
On 05/28/2015 08:42 AM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 8:29 AM, Richard Henderson wrote:
>> On 05/28/2015 04:27 AM, H.J. Lu wrote:
>>> You get consecutive jmpq's because x86 PLT entry is used as the
>>> canonical function address. If you compile main with -fno-plt -fPIE, you
>>> get:
>>
On Thu, May 28, 2015 at 8:29 AM, Richard Henderson wrote:
> On 05/28/2015 04:27 AM, H.J. Lu wrote:
>> You get consecutive jmpq's because x86 PLT entry is used as the
>> canonical function address. If you compile main with -fno-plt -fPIE, you
>> get:
>
> Well, duh. If the main executable has no P
On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote:
>> On May 28, 2015, at 11:59 AM, Richard Biener
>> wrote:
...
>> Maybe follow s390 -mhotpatch instead?
>
> Regarding implementation of the option, it will follow what s390 is doing
> with function attributes to mark which functions to apply nop-trea
On 05/28/2015 04:27 AM, H.J. Lu wrote:
> You get consecutive jmpq's because x86 PLT entry is used as the
> canonical function address. If you compile main with -fno-plt -fPIE, you
> get:
Well, duh. If the main executable has no PLTs, they aren't used as the
canonical function address. Surely yo
On Thu, May 28, 2015 at 10:47:53AM -0400, David Edelsohn wrote:
> This seems like a problem with the cost model. Rc instructions are
> more expensive and should be represented as such in rtx_costs.
The record instructions do have a higher cost (8 vs. 4 for normal
insns). If the cost is increaed
On Thu, May 28, 2015 at 10:39 AM, Alan Modra wrote:
> The problem is that the following testcase on powerpc64le now
> generates worse code.
>
> void foo (signed char *p) { if (*p != 0) *p = 1; }
>
> before after
> foo:foo:
> lbz 9,0(3)
It's really annoying when you fix a combine bug and get worse code..
The following was part of a larger patch. What this part does is
simply not throw away useful info about non-zero bits. The upper bits
that "we don't know anything about" are not those indicated by
last_set_mode, because nonzer
Adding ia32/x86-64 psABI.
On Wed, May 27, 2015 at 5:44 PM, H.J. Lu wrote:
> On Wed, May 27, 2015 at 1:03 PM, Richard Henderson wrote:
>> There's one problem with the couple of patches that I've seen go by wrt
>> eliding
>> PLTs with -z now, and relaxing inlined PLTs (aka -fno-plt):
>>
>> They'r
> On May 28, 2015, at 11:59 AM, Richard Biener
> wrote:
>
> On May 28, 2015 10:39:27 AM GMT+02:00, Maxim Kuvyrkov
> wrote:
>> Hi,
>>
>> Akashi-san and I have been discussing required GCC changes to make
>> kernel's livepatching work for AArch64 and other architectures. At the
>> moment livep
On May 28, 2015 10:39:27 AM GMT+02:00, Maxim Kuvyrkov
wrote:
>Hi,
>
>Akashi-san and I have been discussing required GCC changes to make
>kernel's livepatching work for AArch64 and other architectures. At the
>moment livepatching is supported for x86[_64] using the following
>options: "-pg -mfent
Hi,
Akashi-san and I have been discussing required GCC changes to make kernel's
livepatching work for AArch64 and other architectures. At the moment
livepatching is supported for x86[_64] using the following options: "-pg
-mfentry -mrecord-mcount -mnop-mcount" which is geek-speak for "please a
27 matches
Mail list logo
