Hi everyone,
I made the following notes while backporting Alan Modra's patch for PR26026
to 3.3 series. There's been some major refactoring going on in the fold-const
stuff, and I made some notes about what needed changing in order to realign
snippets of fold() from 4-series with the former semantics and interfaces of
3-series.
I thought it might conceivably be of interest to other people. For
instance, the PR above was causing a call to __udivsi3 which could and should
have been a single shift instruction; issues like this matter a lot to people
working in small/embedded/time-critical areas, plenty of people are still
working with 3.x, and so there are some worthwhile changes to bring back from
4.x series. Backporting the odd patch here and there to address specific
problems that people are encountering with their legacy compilers seems a
worthwhile activity to me.
I could write it up as a page on the wiki if so, but I don't know how right
I got it, and I'm sure there are far more issues than I touched on in the
course of porting one small patch, so I thought I'd ask for advice: is it
worth doing, am I even roughly on the right lines, does anyone else have any
notes or experience they could contribute?
Here are the points I ran into:
-----------------------------snip-----------------------------
TYPE_UNSIGNED can be replaced by TREE_UNSIGNED (assuming it is being applied
to a type tree; if not, use TREE_UNSIGNED (TREE_TYPE (tree)) instead?)
fold_build* (....) can be replaced by fold (build (...)); build1
should be used in place of build for fold_build1, but 3.x does not have
any other build* constructs, just the generic build ().
fold_convert has changed in semantics substantially:
previously it attempted to simplify an existing type conversion expression
of a constant down to a simple constant of the correct type, and if it could
not do so returned the original type conversion expression unaltered.
in 4.x it has full responsibility for generating the type conversion
expression in the first place as well as simplifying it, so rather than
being passed an existing type conversion expression and a constant, it is
passed a desired type and an expression of arbitrary complexity to be
converted
to that type.
to emulate this behaviour in 3.x, any back-ported calls to fold_convert should
be replaced to calls to a simple wrapper. This could be:
static tree
build_fold_convert (t, arg1)
tree t;
tree arg1;
{
tree fc_expr = fold (build1 (NOP_EXPR, type, arg1));
return fold_convert (fc_expr, arg1);
}
-----------------------------snip-----------------------------
Then I could add a couple of worked examples to show how it's done it in
practice.
cheers,
DaveK
--
Can't think of a witty .sigline today....
