On 1/6/22 11:35, Martin Liška wrote:
On 1/6/22 17:20, Andrew MacLeod wrote:
So if you get a FALSE back, you cannot use any results because GORI
is claiming that it cant figure something out... or there is nothing
to figure out. Most of rangers routines are implemented so that if
they return FALSE, the result is meaningless.
All right, then it's my bad, sorry for the noise.
what is IDX you are passing? order_385?
Yep.
(gdb) p idx
$1 = <ssa_name 0x7ffff7733e10 383>
As a side note, theres a typo in the testcase: .. Im not sure how
that affects things, but :
Oh, yeah, that's typo :)
defaut:
__builtin_unreachable ();
default is misspelled... maybe it thinks that some kind of runtime
value? I am surprised it even compiles. maybe that is mucking up
what GORI thiunks it can calculate?
But it does not affect anything. The bailout happens due to:
│ 199 // Only process switches if it within the size limit.
│ 200 if (EDGE_COUNT (e->src->succs) > (unsigned)m_max_edges)
│ > 201 return NULL;
Cheers,
Martin
yeah its created by:
gori_compute::gori_compute (int not_executable_flag)
: outgoing (param_evrp_switch_limit), tracer
("GORI ")
so as long as you change it to whatever you want before you create a
ranger, you should get whatever limit you want. anything above 255 may
produce imprecise default values, if there are big holes in the switch
because multi ranges only currently support up to 255 ranges.. so if
there are more than 255 distinct subranges, it wont be exact.
Andrew
