Aditya,
the hot/cold partitioning is currently organized as folows:
1) we have static branch prediction code in predict.c and profile
feedback which we store into cfg and callgraph.
2) we have predicates
optimize_*_for_speed_p/size_p
where * can be function, basic block, cfg edge, callg
Hi Martin,
Thank you for explaining the status quo. After reading the code of bb-reorder.c,
it looks pretty good and seems it doesn't need any significant improvements.
In that case, the only value GIMPLE level hot/cold splitting could bring is to
enable aggressive code-size optimization
by mer
On 03/03/2020 15:57, Richard Sandiford wrote:
Andrew Stubbs writes:
Hi all,
Up until now the AMD GCN port has been using exclusively 64-lane vectors
with masking for smaller sizes.
This works quite well, where it works, but there remain many test cases
(and no doubt some real code) that refus
Andrew Stubbs writes:
> Hi all,
>
> Up until now the AMD GCN port has been using exclusively 64-lane vectors
> with masking for smaller sizes.
>
> This works quite well, where it works, but there remain many test cases
> (and no doubt some real code) that refuse to vectorize because the
> numbe
Hi all,
Up until now the AMD GCN port has been using exclusively 64-lane vectors
with masking for smaller sizes.
This works quite well, where it works, but there remain many test cases
(and no doubt some real code) that refuse to vectorize because the
number of iterations (or SLP equivalent)
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
--- Begin Message ---
Hi!
On 2019-06-04T23:05:53+0100, Julian Brown wrote:
> I've pushed a new branch "openacc-gcc
Hello.
Thank you for idea. I would like to provide some comments about what GCC can
currently
do and I'm curious we need something extra on top of what we do.
Right now, GCC can do hot/cold partitioning based on functions and basic
blocks. With
a PGO profile, the optimization is quite aggressiv
