Perry Smith <[EMAIL PROTECTED]> writes:
> How do I keep track of the "LTO" design process? I may not be able
> to help 'cause I don't know enough about gcc's internals but I'd like
> to if possible.
You read the mailing list [EMAIL PROTECTED] So you're already doing
the right thing.
Ian
> I see, in the code in svn trunk the compares aren't optimized away
> yet. You must be having a lot of fun right now. ;-)
*That* is an understatement. Unfortunately, reload hates me (see
archives for that thread) so I can't commit anything yet.
> Unless I'm delirious (it's way past bedtime) I see a m32c port
> and it's cc0-free. Is there a problem?
m32c has a separate $flg register defined, not a cc0 port.
Hence, this pattern:
(define_insn_and_split "cbranch4"
[(set (pc) (if_then_else
(match_operator 0 "m32c_cmp_operat
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote:
> Unless I'm delirious (it's way past bedtime) I see a m32c port
> and it's cc0-free. Is there a problem?
I see, in the code in svn trunk the compares aren't optimized
away yet. You must be having a lot of fun right now. ;-)
brgds, H-P
On Wed, 15 Feb 2006, DJ Delorie wrote:
> I hope I can stick with my cmp/jmp model and manage them myself still,
> though, because there's a LOT of patterns in m32c where the set of
> flags affected depends on which alternative you select, and most
> patterns affect the flags in some (usually nonort
> ...and cbranch (cc setter + user in one combined insn) which are
> split after reload.
I have the cbranch and split, but allow it before reload. So far that
hasn't been a problem, although I split it only to delete the cmp if I
can.
> No "unless" here. You either have a clobber or a set in a parallel
> with the main feature, and you lose out on all the
> single_set-directed optimizations if you put in a "set" early.
"Oh, crap"
I hope I can stick with my cmp/jmp model and manage them myself still,
though, because there's a
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote:
> FWIW, I use
> peephole2s and condition code modes in CRIS w.i.p.
...and cbranch (cc setter + user in one combined insn) which
are split after reload.
brgds, H-P
On Wed, 15 Feb 2006, DJ Delorie wrote:
> > BTW, carry-out from shifts is very rarely used in compiled code.)
> Unless you've expanded SI shifts into a pair of HI shifts.
>
> > Besides what DJ said about performance (both pros and cons
> > there), the problem is as I said with port complexity, becau
> BTW, carry-out from shifts is very rarely used in compiled code.)
Unless you've expanded SI shifts into a pair of HI shifts.
> Besides what DJ said about performance (both pros and cons
> there), the problem is as I said with port complexity, because
> of the way you have to handle condition c
On Thu, 16 Feb 2006, Sylvain Munaut wrote:
> What I was thinking for the moment was to have :
> - sign is always the msb of the last ALU output
> - add/sub to modify all flags
> - move/xor/and/not/or only affect zero (and sign)
> - shift operations always affect carry and zero
> - Have some sp
> What's so bad about have the flag as side-effects ?
You can't put any other insn between the compare and the jump. Like,
if you wanted to move an address into a register to do the jump, you'd
lose the condition bits.
The advantage of having most insns set flags, is you can sometimes
avoid the
Hans-Peter Nilsson wrote:
> On Wed, 15 Feb 2006, Sylvain Munaut wrote:
>
>> * 2 flags Carry & Zero for testing.
>
>
> I think most of your questions have been answered, so let me
> just add that if nothing else, the port will be much simplified
> if you make sure that only specific compare
Denis Chertykov <[EMAIL PROTECTED]> writes:
> Code fragment from reload1.c: reload()
>
> if (caller_save_needed)
> setup_save_areas ();
>
> /* If we allocated another stack slot, redo elimination bookkeeping. */
> if (s
Hans-Peter Nilsson wrote:
On Wed, 15 Feb 2006, Sylvain Munaut wrote:
* 2 flags Carry & Zero for testing.
BTW, it depends on the compare (and branch) instructions whether
just two flags are sufficient.
That's true. MIPS for example seems to get by with no flags, although
it makes
Thanks guys.
I was misusing a shared_ptr. I had two shared_ptr's pointing to the
same object (that didn't know about each other).
I apologize if this was more appropriate for gcc-help. Some of the
details of how dtors get called is still magic to me and I thought it
may be gcc specific.
On Wed, 15 Feb 2006, Sylvain Munaut wrote:
> * 2 flags Carry & Zero for testing.
I think most of your questions have been answered, so let me
just add that if nothing else, the port will be much simplified
if you make sure that only specific compare instructions set
condition codes, i.e. not
On Wed, 2006-02-15 at 05:52, Denis Nagorny wrote:
> Did I understand your idea correctly? Can you comment new patch version.
> It isn't fully tested but am I going in right direction?
Yes, that is what I was suggesting.
In choose_reload_regs, you only need one regno_clobbered_p call, with
sets ==
> > Well, cmpsi2 for example. and divsi2.
>
> You mean divsi3? Many targets don't have div at all.
Er, right. divsi3.
On Feb 15, 2006, at 7:27 AM, Perry Smith wrote:
I am assuming I am doing something wrong but I am hoping someone can
give me a clue as to where to look.
I'd fire up a debugger and type up a couple of times from a
breakpoint in the dtor. If you want to randomly try things, if you
inserted c
On Wednesday 15 February 2006 20:06, DJ Delorie wrote:
> > > Note that there are some operations that gcc assumes you have 32-bit
> > > opcodes for, though. Or at least insns that emulate it.
> >
> > Like what ?
>
> Well, cmpsi2 for example. and divsi2.
You mean divsi3? Many targets don't have d
> > Note that there are some operations that gcc assumes you have 32-bit
> > opcodes for, though. Or at least insns that emulate it.
>
> Like what ?
Well, cmpsi2 for example. and divsi2.
DJ Delorie wrote:
>>So If I use 16 bits registers, do I have to handle pairs of them to form
>>32 bits ?
>
>
> Well, you don't *have* to if your word size is only 16 bits. GCC will
> still pair them, but you'll need to tell gcc how to split them back up
> for the opcodes you have available.
>
>
On Feb 15, 2006, at 13:28, John David Anglin wrote:
Understood. My question was what should the define for
WIDEST_HARDWARE_FP_SIZE be when generating code for a target
with no hardware floating point support (e.g., when
TARGET_SOFT_FLOAT is true)?
Practically, I'd say it should be 64, as it'
> On Feb 15, 2006, at 11:44, John David Anglin wrote:
> > I missed this "new" define and will try it. Perhaps, this should
> > take account of the situation when TARGET_SOFT_FLOAT is true. For
> > example,
>
> When emulating all software floating-point, we still don't want to
> use 128-bit float
On Feb 15, 2006, at 11:44, John David Anglin wrote:
I missed this "new" define and will try it. Perhaps, this should
take account of the situation when TARGET_SOFT_FLOAT is true. For
example,
When emulating all software floating-point, we still don't want to
use 128-bit floats. The whole idea
> + /* The widest floating point format supported by the hardware. Note that
> +setting this influences some Ada floating point type sizes, currently
> +required for GNAT to operate properly. */
> + #define WIDEST_HARDWARE_FP_SIZE 64
I missed this "new" define and will try it. Perhaps,
On 15 February 2006 15:27, Perry Smith wrote:
> I am assuming I am doing something wrong but I am hoping someone can
> give me a clue as to where to look.
>
> I'm trying to write an AIX device driver using g++.
^^^
Clue: Look here! ;-)
> The
I am assuming I am doing something wrong but I am hoping someone can
give me a clue as to where to look.
I'm trying to write an AIX device driver using g++. The drivers do
not have a __start or main, so I have to call the global constructors
and destructors myself. I've written code attempting
On Wed, Feb 15, 2006 at 10:07:42AM +0100, Fran?ois-Xavier Coudert wrote:
> > I have got massive FORFRAN test failures on Linux/ia64 and
The name of the language is "Fortran" not "FORTRAN".
> I did see the following on my nightly regtest on x86_64-linux:
>
> FAIL: gfortran.dg/char_transpose_1.f90
How do I keep track of the "LTO" design process? I may not be able
to help 'cause I don't know enough about gcc's internals but I'd like
to if possible.
On Feb 13, 2006, at 2:47 PM, Mark Mitchell wrote:
Gabriel Dos Reis wrote:
Tom Tromey <[EMAIL PROTECTED]> writes:
[...]
| I think it wo
On 2/11/06, Karel Gardas <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> it's been a while since my last comparison of various GCC's compilation
> performance on MICO sources. A lot happened in GCC development since
> then and so I'm here with more up-to-date measurements. This time I've
> used MICO 2.
Jim Wilson wrote:
I don't believe this is safe. If you look at the uses of
regno_clobbered_p in reload.c, the comments clearly indicate that we are
looking for registers used in clobbers. So unconditionally adding code
that handles REG_INC notes will break these uses. You have to add the
RE
Aldy Hernandez wrote:
>> You could combine the two ideas: a global hash table of types used in
>> casts, where each entry had a list of functions using those types. That
>> should take up no more storage than the per-function vectors. Then,
>> you'd have to walk the entire hash table, writing out
> I have got massive FORFRAN test failures on Linux/ia64 and
> Linux/x86-64:
>
> http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00730.html
> http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00729.html
>
> Most of failures look like:
>
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg
Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> acats test cxg2014 hangs forever on hppa2.0w-hp-hpux11.00.
> ,.,. CXG2014 ACATS 2.5 06-02-10 18:02:32
> - CXG2014 Check the accuracy of the SINH and COSH functions.
>* CXG2014 sinh(1) actual: 7.49632E
36 matches
Mail list logo
