[patch] Fix PR43519: Bootstrap with Graphite enabled fails in Java libs

[Richard Guenther]

On Wed, 7 Apr 2010, Diego Novillo wrote:

> On 4/7/10 09:58 , Richard Guenther wrote:
> > On Wed, Apr 7, 2010 at 3:55 PM, Diego Novillo <dnovillo@google.com> wrote:
> >> On 4/7/10 09:42 , Richard Guenther wrote:
> >>> On Wed, Apr 7, 2010 at 3:40 PM, Sebastian Pop <sebpop@gmail.com> wrote:
> >>>> On Wed, Apr 7, 2010 at 03:23, Richard Guenther <rguenther@suse.de> wrote:
> >>>>> As said in the PR you should be using build_nonstandard_integer_type,
> >>>>> not lang_hooks.types.type_for_size (which can return NULL).
> >>>>>
> >>>>
> >>>> As said in the PR comment 7, chrec_convert and niter estimation fail
> >>>> when build_nonstandard_integer_type is used in Graphite as they call
> >>>> unsigned_type_for and signed_type_for that return NULL on non standard
> >>>> types as returned by build_nonstandard_integer_type.
> >>>>
> >>>> I think that unsigned_type_for and signed_type_for could be
> >>>> implemented to be a bit more middle-end friendly by returning
> >>>> build_nonstandard_integer_type instead of returning NULL_TREE.
> >>>
> >>> Well, they are all frontend things and should not be used by the
> >>> middle-end really.
> >>
> >> How about creating a GIMPLE type to represent them?
> > 
> > There was a half-way transition of getting rid of the langhooks
> > used in those functions, Jakubs patch to add a cache to
> > build_nonstandard_integer_type is another step.
> > 
> > Adding another set of functions might be more confusing than
> > useful here.
> 
> Sorry, I'm confused.  If we added them as gimple types, then the
> existing langhooks don't need to be rewritten, they're simply routed to
> the gimple variants.
> 
> Perhaps I'm just not understanding your comment about adding another set
> of functions.

Oh, yes.  But the types are looked up via the langhook (which LTO
for example implements on its own).  Also not all languages use
the global integer_types[] array for this purpose (look at Java
for example).  So the idea was to simply get rid of the langhook
and make all frontends use integer_types[] so a common implementation
(and then your idea of adding the types) works.

Note also that compared to build_nonstandard_integer_type
the type_for_size langhook may return a type with a precision
that is not what was specified (but it can be larger).

Both type_for_size and type_for_mode should be completely
middle-end concepts (and thus frontend uses need to be
examined).

Richard.