This is the mail archive of the
mailing list for the GCC project.
Re: Additional BOFs for the GNU Cauldron?
- From: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- To: Richard Biener <rguenther at suse dot de>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 2 Sep 2016 22:58:13 +0530
- Subject: Re: Additional BOFs for the GNU Cauldron?
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LSU.firstname.lastname@example.org>
On 2 September 2016 at 14:49, Richard Biener <email@example.com> wrote:
> There seems to be plenty of slots available on the 2nd track to
> schedule additional BOFs. So I'd gather if there is interest
> in discussing
> A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing),
> basically how people feel about moving forward here and how
> this would affect the current testsuite structure
I'd be looking forward to this BOF, in particular GIMPLE FE.
There are a couple of issues which I would like to discuss:
a) Extending to IPA passes: Currently the desired passes to run are
function which restricts it to tree-ssa passes. At the simplest level
we could specify
ipa passes by command line option, -fgimple -fipa-passes=<pass-list>"
but that would
be admittedly ugly -;) In the longer term it would be nice if we can
have sth similar
to llvm opt tool (http://llvm.org/docs/CommandGuide/opt.html) for GIMPLE
b) Handling PHI's - AFAIK, phi's are handled currently by emitting an
internal function from FE,
and then lowering it to a real phi node in cfg pass ? It would be
interesting to experiment
if we could emit a lowered CFG directly from FE, but not sure if this
would be of high priority.
> B) GIMPLE evolution. With LTO early debug we could finally remove
> some tree slack at some point in the compilation. There is
> also increasing need to somehow represent multiple outputs
> from a GIMPLE stmt (we've used complex types as a workaround
> in some cases) -- esp. if we would consider moving GIMPLE further
> into the backend area by lowering it and for example performing
> instruction selection on GIMPLE (we'd need to represent flag
> registers, etc.)
> C) Vectorizer. There's no vectorizer specific talk yet, the usual
> suspects would be an update from the we-rewrite-the-vectorizer
> folks and ideas about how to improve cost modeling.
> If there's no strong interest in any of the above we can schedule
> stuf as needed at the Cauldron itself as well.
> Richard Biener <firstname.lastname@example.org>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)