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: Great example of why "everything is a tree" sucks

On Tue, Nov 12, 2013 at 10:25 PM, Jeff Law <> wrote:
> On 11/12/13 13:35, Jakub Jelinek wrote:
>> On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote:
>>> So I lost something like 3 hrs last night due to writing a hunk of
>>> code like this
>>> if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt)))
>> INTEGRAL_TYPE_P is a macro, which accepts everything, just adding
>> a TYPE_CHECK to that macro would be sufficient to catch that
> Yes, I know full well that I could hack up INTEGRAL_TYPE_P to detect this
> case and my brain damage would have been caught via the check sometime
> during building the runtime libraries or the stage2 build.
> My point is the mere need to hack up INTEGRAL_TYPE_P in that way is a result
> of a fundamental misdesign of the tree structures.  If the structures were
> properly designed what I did would have been flagged as a compile error.
> It's that fundamental mis-design that we're trying to correct now with the
> work from Andrew, David & others.

You know - 'tree's were a design decision (well, just my guess - I wasn't
around 25 years ago ...).  They are a perfect match to represent an AST.
So I'd say whoever introduced that middle-end between the FEs AST
and RTL was at fault :P  (luckily I wasn't around either ... ;))

Still splitting 'tree's into a few separate classes is not hard.  It's just
work - and in the end even the frontends will benefit.  Oh, and I believe
it is a project that has a much higher success rate than trying to
replace trees with "something else" in the GIMPLE and RTL middle-end
only and have that cooperate sanely with the rest of the compiler.
Something along 1 man year for the first with a 75% success chance
against 6 man years for the second with a 20% success chance.
And the nice thing is that the first can be done incrementally
(we _are_ already in the process of that transition - see the changes
done to 'tree' during the last 6 years).  And the other nice thing is that
even non-100% success will end up in something better than we have now.
With the second project it's a all-or-nothing (or rather


> Jeff

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