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
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
checkboxes during installation.
Yours,
Björn Haase
BTW: Maybe your question is probably better posted on the gcc-help list.
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_procedural optimization. Between
procedures
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),
[EMAIL PROTECTED] wrote on Mittwoch, 15. Juni 2005 18:31 :
Hello, I'm trying to compile a simple program with gcc on windows and am
getting really frustrated. I've tried entering the commands in command
prompt (no ms-dos mode, I have XP) and Run, but can't get anything,
mostly something like
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-carrys at expand, I
Hi,
During the last weeks I have experimented a bit with the AVR back-end. IMO
there presently are two areas where it is worth to concentrating efforts on:
1.) cc0 - CCmode transition
2.) splitting of HI- and SI-mode operations so that the RTL finally gets some
similarity with the actually
Am Samstag, 4. Juni 2005 15:04 schrieb Paolo Bonzini:
(parallel [
(use (operands[0]))
(set (operands[0]) (minus:HI (operands[1]) (operands[2]))
(note please delete the entire embracing parallel instruction before
register life-time analysis by a new pass: It pretends to use operands 1
Am Freitag, 3. Juni 2005 10:48 schrieb Mark Mitchell:
DJ Delorie wrote:
Do we have a standard way of telling the testsuite how big target
types are, or some standard this test assumes 32 bit int dejagnu
flag?
I don't think we have any way of doing this at present. I could be
wrong,
Hi,
I am observing a bootstrap failure for the avr target that seems to be related
to the patch
2005-05-19 Jan Hubicka [EMAIL PROTECTED]
...
* basic-block.h (REG_BR_PROB_BASE): Define.
...
* rtl.h (REG_BR_PROB_BASE): Kill.
. Bootstrap using the switches
configure
Jan Hubicka wrote, Friday May 20th
The attached patch seems to fix the problem to me (at least to the point
so I can build cc1 binarry). What kind of other problems you are
seeing?
thank you for your fast response. After applying your patch, bootstrap
succeeds again also on my machine.
Jan Hubicka wrote, Friday May 20th
The attached patch seems to fix the problem to me (at least to the point
so I can build cc1 binarry). What kind of other problems you are
seeing?
... just realized that you have still reported the problem that build stops at
the cc1 level: This is
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
Am Samstag, 14. Mai 2005 21:39 schrieb Alexandre Oliva:
On May 14, 2005, Bjrn 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 after expand
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 stdout
Best thanks for your fast reply!
... did not know that gdb has support for printing RTX. *VERY* useful feature
(and much better than temporary including debugging printout commands in the
compiler itself :-) ).
Yours,
Björn
Hello,
when working on the AVR target I stepped over the follwoing issue (IMO not
urgent but still bearing quite some potential of improvement):
When implementing lowering of SImode and HImode expressions to QImode
sequences by splitters after reload, quite a number of new optimization
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
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
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
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 sent to
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 :-) (and
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
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
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
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
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
Hi,
some of you possibly remember that I had sent you a mail recently, stating
that the avr port was broken again. A bug that I myself was not able to
reproduce a couple of minutes later. I now have found the origin. It seems
that there indeed is a bug:
I have just been checking out the
29 matches
Mail list logo
