This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: using scratchpads to enhance RTL-level if-conversion: the new patch is almost ready to be prepared for merging to trunk, but not 100% ready yet


> From: Jeff Law <law@redhat.com>

> Sent: Friday, September 25, 2015 11:09 AM


> I'd be surprised if we had DEBUG_INSNs as the first insn in a block 
> (before the note), but it can't hurt to verify.  I believe cfgrtl checks 
> for proper location of the block note.  But maybe I'm mis-remembering. 
> It might not be a bad idea to run the verification code immediately 
> after your transformation (for testing purposes only).

Thanks for the advice.


By "run the verification code", did you mean:

  * call some code whereby "cfgrtl checks for proper location of the block note"?

  * re-use some other already-existing-in-GCC code?

  * write some new verification code of my own?


By "after your transformation", did you mean:

  * just before my code does "goto success;", which jumps to a point
    in "noce_process_if_block" that was already there and is shared
    between several different RTL-level if conversions?

  * well after the relevant "success:" but before returning?

  * both of the preceding?

  * "other"?



> Otherwise, you're just going to have to slog through and find out why 
> the codegen is different.  These kind of bugs are usually painful to 
> track down, but it's usually worth the time spent in the end.


Yeah.  I think I understand.  I hope I`ll be able to figure it out at the RTL level.

Thanks again for your help, Jeff.

Regards,

Abe


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