This is the mail archive of the 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: [PATCH 012/236] Convert DF_REF_INSN to a function for now

On 08/13/14 18:11, David Malcolm wrote:
On Wed, 2014-08-13 at 14:34 -0600, Jeff Law wrote:
On 08/13/14 14:28, David Malcolm wrote:
Thanks.  Although this function gets converted back to a macro in patch
191, I just realized that in the meantime that it's not inlined, as is
the case for some of the other macro->function conversions in patches

Do I need to convert them to inline functions with the appropriate
headers, and is that regarded as a sufficiently trivial fix to the stuff
you've already reviewed to not need re-review? (I will bootstrap&test).
I'd just make it a follow-up. #237 ;-)

Right, but these would be modifications to stuff that only exists
between phases 1-3 of the kit, before going away in phase 4, so although
it might be #237, it would need to be applied when the individual
changes go in.
If they're around just through phases #1-#3, then I wouldn't worry about it.

Transient, yes, but given the amount of time for me to simply bootstrap
each candidate patch, the non-inlined functions could last in trunk for
a couple of weeks (there are only 168 hours in a week, and a bootstrap
+regrtest takes about 3 hours on my box, so for 236 patches we're
talking ~4 weeks of compute time just for that).
Well, I'd suggest a few things.

1. For the config/ changes, a full bootstrap is not necessary. For those targets which are embedded, just build a stage1 cross to the target to verify it builds and call it good.

2. For targets where you can bootstrap, go ahead and do so, but just on those targets. Some of these you can probably have going in parallel.

3. Some of the changes are so trivial that I'd squash them together in a single build/test cycle.

I would even consider seeing all the scaffolding go in as a single chunk. It's nice to see the individuals during the review process, but I wouldn't lose any sleep if bundled those together.

I guess the underlying point here is that this is a big change and I'm
trying to be fastidious here.  Murphy's Law suggests I'm going to break
at least *something* :(
Understood, but we don't want to be so fastidious that the time this stuff is in flux is so long that it creates more problems than it would if we took some sensible and safe shortcuts.


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