Re: gcc/ia64 codegenerator questions

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On Wed, 28 Aug 2002 14:09:43 -0400 (EDT), robert.muth@intel.com said:

  Robert> My group is working on a tool to optimize ia64 binaries.
  Robert> It already works with images produced by intel compilers.
  Robert> and I am trying to make it work for gcc as well.
  Robert> I am using gcc 3.1 so my observations might already be outdated.

  Robert> * break instructions  after non returning calls

  Robert> I believe that gcc tries to put a break instruction
  Robert> after a call to functions like abort.
  Robert> This is very useful to us as it keeps us from having
  Robert> "impossible" control edges in our cfg.
  Robert> I think this also necessary for "unwind" to work correctly.

Yes, unwinding is indeed the reason the break is being emitted.

  Robert> the problem is that with -O3 the break seems to get optimized
  Robert> away. This can be reproduced with the following simple program:

  Robert> #include  <stdlib.h>
  Robert> void do_abort ()
  Robert> {
  Robert>   abort ();
  Robert> }

This looks like a bug to me.  It happens even with -O2 and gcc-3.2 has
the same problem.

  Robert> * delayed saving of ar.lc

  Robert> In the code snippet below the prolog ends rather late
  Robert> and even includes a call. Is this intentional or
  Robert> is this a bug?

It's a bit strange, but I think it's correct.  ar.lc doesn't get saved
until very late and that's why the .body directive gets emitted so late.
I don't think there is any problem with having a call inside the prologue
(not as far as the ia64 unwinder is concerned, at least).

  Robert> * tail calls

  Robert> It seems to me that tail calls are a little bit fragile
  Robert> with respect to "unwinding".
  Robert> In the code snippet below the alloc instruction
  Robert> just before the actual tail call will hide the registers
  Robert> r40 and r39. If I set a breakpoint at the last nop.i
  Robert> in the debugger and try to unwind from there I might
  Robert> have a problem.

I believe this has been fixed.  If you have a complete test case, I
can confirm.

  Robert> * slotting of calls

  Robert> this is more question than a problem:

  Robert> Does gcc always place call instructions in the last slot
  Robert> of a bundle -- call shadows are a nasty problem to deal
  Robert> with on our side.

Not sure I would count on this being the case.  It may well be true
now (I don't know for sure), but there could easily be cases where
putting multiple call instructions in the same bundle makes sense.
(We definitely have such a case in hand-coded assembly in the Linux
kernel.)

	--david