This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Calling gen_nop.


>   In message <200004061525.QAA16250@cam-mail2.cambridge.arm.com>you write:
>   > The code in question is in compile_file() and reads:
>   > 
>   >   if (profile_flag || profile_block_flag)
>   >     {
>   >       /* It's best if we can write a nop here since some
>   >          assemblers don't tolerate zeros in the text section.  */
>   >       output_asm_insn (get_insn_template (CODE_FOR_nop, NULL), NULL_PTR);
>   >     }
>   > 
>   > Is it safe to call gen_nop() here to create a real insn?  If so, what, if 
>   > anything, will I need to reset after emitting the insn?  Is there a better 
>   > way of solving this?
> Ugh.  Gross. 

Which is why I asked if anyone could think of a better way...  It was 
always a bit gross, and this is likely to make it worse.

> 
> Anyway, you can probably deal with this with something like
> 
> (define_insn "nop"
>   [(clobber (const_int 0))]
>   ""
>   "*
> {
>   if (TARGET_ARM)
>     return "mov%?\\t%|r0, %|r0\\t%@ nop";
>   else
>     return "mov\\tr8, r8";
> })
> 


Nope.  Tried that.  The code in get_insn_template aborts if the template 
is a function and there is no rtl to pass to it as a parameter.

What should work is to add something like the following:

  if (...)
    {
      rtx insn = gen_nop();

      recog (insn);
      output_asm_insn (get_insn_template (INSN_CODE (insn), insn),
		       recog_operands);
      /* GC insn.  */
    }

Garbage collecting the insn is a no-op with the GC code, but might be a
bit more work without, unless we can assume that the rtl will just be on 
the normal rtl obstack and will be reclaimed at the end of the first 
function.  But will this upset other code concerned with generating insns 
for a function?  Is it even safe to call gen_nop at this point in the 
compilation?

> I'd consider it a band-aid since we'd really like a better way to deal with
> this problem.

Yes, it strikes me as a hack that we are even generating a nop here.  
Better general solutions would always be appreciated.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]