On 6/24/24 22:35, Andrew Pinski wrote:
On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod <amacl...@redhat.com> wrote:
// Fill ssa-cache R with any outgoing ranges on edge E, using QUERY.
bool gori_on_edge (class ssa_cache &r, edge e, range_query *query =
NULL);
This is what the fast_vrp routines uses. We can gather all range
restrictions generated from an edge efficiently just once and then
intersect them with a known range as we walk the different paths. We
don't need the gori exports , nor any of the other on-demand bits where
we calculate each export range dynamically.. I suspect it would reduce
the workload and memory impact quite a bit, but I'm not really familiar
with exactly how the threader uses those things.
It'd require some minor tweaking to the lazy_ssa_cache to make the
bitmap of names set accessible. This would provide similar
functionality to what the gori export () routine provides. Both
relations and inferred ranges should only need to be calculated once per
block as well and could/should/would be applied the same way if they are
present. I don't *think* the threader uses any of the def chains, but
Aldy can chip in.
+ warning (OPT_Wdisabled_optimization,
+ "Using fast VRP algorithm. %d basic blocks"
+ " exceeds %s%d limit",
+ n_basic_blocks_for_fn (fun),
+ "--param=vrp-block-limit=",
+ param_vrp_block_limit);
This should be:
warning (OPT_Wdisabled_optimization, "Using fast VRP algorithm. %d basic blocks"
" exceeds %<%--param=vrp-block-limit=d%> limit",
n_basic_blocks_for_fn (fun), param_vrp_block_limit);
I had thought it was mentioned that options should be quoted but it is
not mentioned in the coding conventions:
https://gcc.gnu.org/codingconventions.html#Diagnostics
But it is mentioned in
https://inbox.sourceware.org/gcc/2d2bd844-2de4-ecff-7a07-b22350750...@gmail.com/
; This is why you were getting an error as you mentioned on IRC.
I didnt do that because when I did, everything in bracketed by the %< %>
in the warning came out in bold text. is that the intended effect?
Andrew.
