On 09/09/2016 10:49 AM, Segher Boessenkool wrote:
On Fri, Sep 09, 2016 at 09:59:03AM -0600, Jeff Law wrote:
On 09/09/2016 09:17 AM, Segher Boessenkool wrote:
On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote:
So can you expand on the malloc example a bit -- I'm pretty sure I
understand what you're trying to do, but a concrete example may help
Bernd and be useful for archival purposes.
Sure, but it's big (which is the problem :-) )
Yea :( But it's likely a very compelling example of real world code.
It's almost certainly too big to turn into a testcase of any kind, but
just some before/after annotated code would be helpful.
I'll work on it, but it won't be before tonight, probably quite a bit
later. Seeing the difference in generated machine code is probably
most useful? Better than RTL ;-)
Yea, machine code is probably most useful.
Ideally we'd have some smaller testcases we could put in the testsuite
to ensure that the feature works over-time in the way intended would be
helpful as well.
I might be able to make some really tiny testcases that will not need
updates all of the time. We'll see.
Understood, particularly on the maintenance burden for these kind of
tests. The alternate approach might be to pick up Bernd's work and see
if we can use that test the various components.
But that is not because it is good to have only one! GCC expects there
to be only one, instead. Some ports might even use prologues that cannot
be duplicated at all.
Agreed on all points.
And in separate shrink-wrapping world, we're leaving that model behind
and I think that's one of the big things I'm struggling with -- we may
execute a prologue component more than once if I've read everything
correctly.
Yes, and that is perhaps radically new in the GCC world, but not anywhere
else.
And just to be clear I think I'm mostly looking for why multiple
execution of a particular component is useful. My first thought in that
case is that we've got a redundancy and that the redundancy should be
identified and eliminated :-)
I've got a few not-well-formed ideas in my head about when that might
happen and why we might not want to squash out the redundancy. But it'd
be a hell of a step forward to see that case in action.
Jeff
