Steven Bosscher wrote:
> In
> any case, you should assume that it is a much bigger job than just
> modifying the call expander.
Ok, I had a closer look at what is happening in present state gcc and I
understand that it is indeed a much more complex task than I first thought.
One Issue would be a
Steven Bosscher wrote on Sonntag, 7. August 2005 12:45 :
> On Sunday 07 August 2005 09:35, Björn Haase wrote:
> > Hello,
> >
> > The avr port presently misses possible intra-procedure optimizations
> > concerning register use.
>
> What you describe is an _inter_p
the right checkboxes during installation.
Yours,
Björn Haase
BTW: Maybe your question is probably better posted on the gcc-help list.
Hello,
The avr port presently misses possible intra-procedure optimizations
concerning register use. Optimizations are missed when 1) calling a leaf
function that is 2) defined in the same unit as a the caller and 3) clobbers
only a subset of the call-clobbered registers. Presently I observe th
> If I use:
> (define_expand "addsi"
> [(set (match_operand:SI 0 "general_operand" "=g")
>(plus:SI (match_operand:SI 1 "general_operand" "g")
> (match_operand:SI 2 "general_operand" "g")))]
> ""
> "{
> emit_insn (gen_addhi3 (custom_subword(operands[0], 0, SImode),
>
Thank's for your response,
Sunday, 5. Juni 2005 04:16 Ian Lance Taylor wrote:
> > The condition-code re-use issue is the point, where, IMO, the link to the
> > subreg-lowering 2.) shows up. After, e.g., breaking down a HI mode "sub"
> > operation into two QI mode "sub" and "sub-with-carry"s at exp
Am Samstag, 14. Mai 2005 21:39 schrieb Alexandre Oliva:
> On May 14, 2005, BjÃrn Haase <[EMAIL PROTECTED]> wrote:
> > I.e. expand
> > would insert two instructions after the double-set instruction that
> > contain the two individual sets and an additional "use" statement. I.e.
> > above sequence af
Hi,
I have thinking about how to overcome part of the "double-setter" difficulties
that arise when implementing cc0->CCmode conversion for a couple of targets:
IIUC correctly one of the two or three difficulties with cc0->CCmode
conversion is, that combine in it's present form is not able to
rec
Hi,
I am facing a situation where a gcc_assert call that checks for some
properties of a rtx expression, say "op", triggers an ICE (see below). I'd
like to have a look the rtx that triggers this error. For this reason, I'd
like to know whether there exists a helper function for writing to stdou
Hi,
brief question:
Would it be ok to make use of inttypes.h in testcases of the C-testsuite?
By replacing, e.g., "int" by "int32_t" where necessary, one could compensate
for the implicit assumption of a hand full of testcases that int is 32 bits
so that they work also for targets where int i
James E Wilson wrote:
> You were never very clear about what was wrong with gen_highpart and
> gen_lowpart with respect to subregs. rtl examples are always helpful,
> e.g. showing RTL input and RTL output and pointing out what is wrong.
> gen_lowpart already has support for subreg input and presu
Martin,
I think that the AVR people would very much appreciate if you would report
occasionally on your progresses concerning your realization of the different
address space issue on your personal HC05 port. (In my opionion, the lack for
support of different memory spaces is the key weakness of
Thank you for your answer!
Am Donnerstag, 21. April 2005 05:11 schrieb James E Wilson:
> Björn Haase wrote:
> > The mid-end seems not to be able to simplify nested subreg expressions.
> > I.e. it seems that there is no known transformation
> >(subreg:QI (subreg:HI (reg:SI
Hi,
when working on removing avr's present monolithic SI-mode instruction patterns
by splitters after reload and lowering to QI modes after expand, I have
stepped over the following general issue:
The mid-end seems not to be able to simplify nested subreg expressions. I.e.
it seems that there
Am Dienstag, 19. April 2005 00:30 schrieb James E Wilson:
> Björn Haase wrote:
> > In case that one should not use machine specific atttributes, *is* there
> > a standard way for GCC how to implement different address spaces?
>
> Use section attributes to force functions/var
James E Wilson wrote
>You shouldn't be trying to build your own types in a machine dependent
>attribute handler function. The compiler's type system is determined by
>front-ends mainly, and some middle-end infrastructure, and isn't your domain
>to mess with. This stuff is subject to change, at
Am Sonntag, 17. April 2005 16:26 schrieb Daniel Jacobowitz:
> On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote:
> > Hi,
> >
> > while lacking the deep insight into GCC internals most of you have, I'd
> > never the less like to ask you to be very
Hi,
while lacking the deep insight into GCC internals most of you have, I'd never
the less like to ask you to be very prudent concerning the issue of removal
of seemingly unnecessary RTL optimizations.
In contrast to 32 bit targets, for 8 and 16 bit targets the RTL representation
possibly might
Hi,
I have been working on very similar issues for the avr target. You might have
a look at the patch I have posted today and the corresponding discussion
thread at the gcc-patches list.
I have also observed, that gen_highpart and gen_lowpart sometimes causes an
ICE for reasons. ... did not f
Am Freitag, 8. April 2005 01:06 schrieb Janis Johnson:
>
> I should have done that, I must have missed seeing your patch. I'll look
> for it now in the archives.
>
> Janis
I just had a look at the archives and found that the subject of the mail I
have been sending was not very clear either :-) (a
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Joseph Myers wrote:
>One possible way of assessing activity would be to say that after 4.1
maintained CPU ports should have test results for mainline regularly
Am Sonntag, 3. April 2005 17:24 schrieb Peter Barada:
> >When trying to figure out the origin of the problem, I have realized so
> > far, that it is obviously stems from a problem during my local configure
> > process: The xgcc I'm just building tries to pipe the asm result through
> > my "host-as"
When trying to figure out the origin of the problem, I have realized so far,
that it is obviously stems from a problem during my local configure process:
The xgcc I'm just building tries to pipe the asm result through my "host-as"
instead of the "target-as". I will myself have to look for why co
Hi,
when checking out the gcc tree this morning for a clean rebuild and regular
testsuite run, I observed that bootstrap failed. It seems that it is related
to some preprocessor issue:
1.) Problem occures when assembling the libgcc library. First failing
operation is
/home/bmh/gnucvs/head/bui
Hello Andy,
I have tested your patch concerning RTL prologue/epilogue. Gratulations: My
testsuite run only reports a single regression
Tests that now fail, but worked before:
gcc.c-torture/execute/20010122-1.c execution, -O0
. This happens on a testcase that anyway is problematic (succeeds o
Hi Paul,
I have the impression that you are trying to open open doors :-) : If IIUC
what Denis aims to do is to segment the re-organization of the back-end into
several independent small steps. One step will be the cc0 -> CC_mode issue he
is addressing now. The splitting issue would be one of t
Hi Denis,
I have had a look at your patch. It generally seems to work. Presently it
still misses some optimization where the old cc0 back-end was smarter. The
testsuite also reports a couple of new failures.
Yours,
Björn.
Here are a couple of cases where the old cc0 interface generated bette
Am Donnerstag, 17. Februar 2005 03:11 schrieb James E Wilson:
> James E Wilson wrote:
> > Björn Haase wrote:
> >> #ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
>
> I see now that this is PR 19920. This message would have made more
> sense if you had included that imp
Hi,
I'd like to discuss with you a topic related to a recent bootstrap failure of
a couple of smaller embedded targets. The origin of the failure could be
removed easily. In my opinion the question is simply, what is the best way to
implement it?
Root of the problem is that libgcc2 presently d
29 matches
Mail list logo
