Hello,
Here's a simple memory copy macro:
#define MYMEMCOPY(dp, sp, len) \
do { \
long __len = len; \
while (--__len >= 0) \
(dp)[__len] = (sp)[__len]; \
} while (0)
void foo(unsigned char *dp, const unsigned char *sp, unsigned long size) {
MYMEMCOPY(dp, s
On Mon, Feb 16, 2009 at 11:19 AM, Narasimha Datta wrote:
> Hello,
>
> Here's a simple memory copy macro:
>
> #define MYMEMCOPY(dp, sp, len) \
> do { \
>long __len = len; \
>while (--__len >= 0) \
>(dp)[__len] = (sp)[__len]; \
> } while (0)
>
> void foo(unsigned char
Hi,
I am comparing the assembly generated by compilers targeting arm-wince
platform and it seems
that cross-compiler from gcc-trunk is less optimized than an old one based
on gcc 4.1.x
Here is the comparison obtained from objdump:
cegcc-4.1.x :
00011000 :
11000: e92d40f0push
Hi,
in machine description expanders the functions copy_to_mode_reg and and
force_reg from explow.c can be used to ensure that an operand lives in a
register.
But what function should be used?
What are the differences? The only difference I can depict from the
comment is that an operand retu
On Mon, Feb 16, 2009 at 12:19:52PM +0100, Vincent R. wrote:
> 00011000 :
>11000: e92d40f0push{r4, r5, r6, r7, lr}
>11004: e1a04000mov r4, r0
>11008: e1a05001mov r5, r1
>1100c: e1a06002mov r6, r2
>11010: e1a07003
On Monday 16 February 2009 11:19:52, Vincent R. wrote:
> I used to have .align 0 with gcc-4.1 and now I get a .align 4, how can I
> change that ?
It was a bug in the patches I had sent you months ago. I've posted the
latest patch I had here at cegcc-devel@ --- it should fix this.
--
Pedro Alves
Steven Bosscher wrote:
On Fri, Feb 13, 2009 at 8:53 PM, Jeff Law wrote:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload?
Ideally
Ian Lance Taylor wrote:
Paolo Bonzini writes:
That is in brief how I see it and there are a lot of reload details
missed (like virtual register eliminations or addressing displacement
constraints etc).
I suppose those would stay in reload?
I see no reason for those to stay in
Vladimir Makarov wrote:
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- the selection of a
Michael Matz wrote:
Hi,
On Fri, 13 Feb 2009, Paolo Bonzini wrote:
We'd want to encode [early insn alternative selection] information in
the conflict graph so that IRA would allocate registers so as to fit
the constraints of the early insn alternative selection. Right? In
the case where
Hi,
On Mon, 16 Feb 2009, Jeff Law wrote:
> > If the initial alternative selection was done cleverly (like chose the
> > alternatives allowing the largest register sets which don't
> > immediately create conflicting demands for a pseudo register) the
> > opportunities for making an uncolorable
On Fri, 2009-02-13 at 12:28 -0800, Joe Buck wrote:
> On Fri, Feb 13, 2009 at 11:03:51AM -0800, Anthony Newnam wrote:
> > Thanks Joe.
> >
> > As far as I know the problem I'm seeing isn't a regression but perhaps
> > this script could still be useful. I don't really understand how it is
> > suppose
What purpose does changed_allocation_pseudos serve? AFAICT we set/clear
the bitmap, but never use it for anything. It was added as part of the
IRA integration. Did you have some purpose in mind for this bitmap? If
not can we just remove it?
Jeff
Jeff Law writes:
> Ian Lance Taylor wrote:
>>
>> I see no reason for those to stay in reload (especially since I think
>> reload should disappear entirely). It is reasonable to pick the total
>> maximum size of the stack frame, and thus resolve all displacement
>> constraints, before register al
Hi,
This is posted partly to start a disscussion, and partly as technical
enquiry.
Granted that this is not strictly GCC related, but in relation to the
GGC toolchain.
Before Java was GPL'ed , comments were made in relation to the so called
'Java' trap.
There is also another 'pit' into
On Tue, Feb 17, 2009 at 8:38 AM, Farlie A wrote:
> In terms of Visual Basic code, there is of course no 'free' compiler for VB
> code written prior
> to VB.NET., and again the EULA for the runtime support would prevent use of
> the Vendor's
> runtime on 'free' systems..
> Should there be a way of
On Tue, 17 Feb 2009 09:03:36 +1100, Carl wrote:
> On Tue, Feb 17, 2009 at 8:38 AM, Farlie A
> wrote:
>
>> In terms of Visual Basic code, there is of course no 'free' compiler for
>> VB
>> code written prior
>> to VB.NET., and again the EULA for the runtime support would prevent use
>> of
>> the
Ian Lance Taylor wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
I see no reason for those to stay in reload (especially since I think
reload should disappear entirely). It is reasonable to pick the total
maximum size of the stack frame, and thus resolve all displacement
constraints,
Status
==
The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.
As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100. We've achieved that, but are st
Jeff Law writes:
>>> I would agree that careful relaxation of displacements is no longer as
>>> important as it once was, I don't think we can just hand wave away
>>> the displacement issues
>>>
>>> 1. The stack frames don't have to be that big to bump up against
>>> these problems.
>>>
>>> 2.
Richard, thanks for the reply.
I'd love to check out the generated code on a later gcc, but unfortunately we
are not in a position to upgrade our gcc. We just use the default gcc that came
with FreeBSD 7.0.
I'm interested in understanding why gcc generates the code the way it does. I'm
probabl
21 matches
Mail list logo
