This is the mail archive of the gcc@gcc.gnu.org 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: Additional BOFs for the GNU Cauldron?


On 2 September 2016 at 14:49, Richard Biener <rguenther@suse.de> 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
specified per
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.

Thanks,
Prathamesh
>
>  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.
>
> Thanks,
> Richard.
>
> --
> Richard Biener <rguenther@suse.de>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)


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