Re: Leaking bitmap data in ree.c?
On Mon, Mar 21, 2016 at 6:19 PM, Jeff Law wrote: > On 03/21/2016 11:16 AM, David Malcolm wrote: >> >> On Mon, 2016-03-21 at 11:13 -0600, Jeff Law wrote: >>> >>> On 03/21/2016 11:15 AM, Trevor Saunders wrote: > I'll resist the urge for now to apply RAII principles in this > code, but > that'd probably a much cleaner way to think about the problem in > general. I worked on a couple attempts to c++ify bitmaps a while back, but never finished any of them, but I could probably publish what I did in case someone wants to pick that up for gcc 7. >>> >>> Can't hurt. >>> >>> FWIW, bitmaps are low level and independent of trees, rtl, etc that >>> we >>> ought to (in theory) be able to class-ify them and build a real unit >>> testing framework for them. >> >> >> Something like: >> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02371.html > > Like that, or complete instantiation outside GCC. I don't like more C++-ification just for the sake of it. Like the alloc-pool C++ification caused more issues than it fixed. I'd happily approve sth like an auto_bitmap class though (bah, we can't have auto as auto is already taken!). Notice that using bitmap_initialize is a micro-optimization to avoid one indirection. I doubt it matters for REE. Also keep in mind bitmap statistics - leaving bitmaps to GC only like REE seems to do will mess them up. Bitmaps that have used bitmap_initialize and allocating from GC need to call bitmap_clear on them. In fact REE should simply use &bitmap_default_obstack, I think that it uses GC is an oversight... Richard. > jeff
Re: [gimplefe] [gsoc16] Gimple Front End Project
On Mon, Mar 21, 2016 at 4:35 AM, Trevor Saunders wrote:
> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>> Hi!
>>
>> Sorry for the late reply.
>>
>> I was observing gimple dumps and my initial findings are, to parse
>> gimple, we have to add support for following components to C FE
>>
>> *basic blocks
>
> I'd think you can probably make these enough like C labels that you
> don't need to do anything special in the C fe to parse these. Just
> removing the < and > gets you pretty close is that it?
>
>> *gimple labels and goto
>
> Similar I think.
>
>> *gimple phi functions
>> iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>
> yesI think you need to add something here. I think you can do it as a
> builtin type function that expects its arguments to be labels or names
> of variables.
Yes.
>> *gimple switch
>> switch (a_1) , case 1: , case 2: >
>
> I'd think we could make this more C like too.
switch (a_1) { default: goto L0; case 1: goto L1; ... }
which is what it boils down to. And yes, we need to adjust label dumping to
dump C-parseable labels.
>> *gimple exception handling
>
> yeah, though note exceptions are lowered pretty quickly so supporting
> them with the explicit exception syntax probably isn't particularly
> important.
True - though if we lowered things already we need to dump/parse the
EH side-info present on the stmts plus the landing pads. I'd simply defer
the issue of EH until at least some of the basic stuff works (read: not in
the GSoC project).
>> *openmp functions like
>> main._omp_fn.0 (void * .omp_data_i)
>
> I'd think you'd want to change the duping of this some to make it easier
> to tell from struct.some.member.
it's just the way we name clones, yes. Similar for the parameter name btw.
>> Please correct me if I am wrong. Also point out if I am missing anything
>
> I think you might need to do something about variable names?
Possibly about how we dump SSA names and how we dump local variable
declarations.
Richard.
> Trev
>
>>
>>
>>
>>
>> On 18 March 2016 at 14:53, Richard Biener wrote:
>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>> > wrote:
>> >> On 15 March 2016 at 20:46, Richard Biener
>> >> wrote:
>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>
>> > Then I'd like to be able to re-construct SSA without jumping through
>> > hoops (usually you can get close but if you require copies propagated
>> > in
>> > a special way you are basically lost for example).
>> >
>> > Thus my proposal to make the GSoC student attack the unit-testing
>> > problem by doing modifications to the pass manager and "extending" an
>> > existing frontend (C for simplicity).
>>
>> I think it's wrong to try to shoehorn the gimple FE into the C FE. C is
>> fundamentally different from gimple and you'd have to sprinkle
>> gimple_dialect_p() all over the place, and maintaining that while
>> developing future C improvements will turn out to be much work. Some
>> differences of C and gimple:
>>
>> * C has recursive expressions, gimple is n-op stmts, no expressions at
>> all
>> * C has type promotions, gimple is explicit
>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>> * C has scopes, gimple doesn't (well, global and local only), i.e.
>> symbol
>> lookup is much more complicated
>> * C doesn't have exceptions
>> * C doesn't have class types, gimple has
>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>> * C doesn't have self-referential types
>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>> gimplifier and again would feed gimple directly into the passes)
>>
>> I really don't think changing the C FE to accept gimple is a useful way
>> forward.
>> >>>
>> >>> So I am most worried about replicating all the complexity of types and
>> >>> decl
>> >>> parsing for the presumably nice and small function body parser.
>> >> Um would it be a good idea if we separate "gimple" functions from
>> >> regular C functions,
>> >> say by annotating the function definition with "gimple" attribute ?
>> >
>> > Yes, that was my idea.
>> >
>> >> A "gimple" function should contain only gimple stmts and not C.
>> >> eg:
>> >> __attribute__((gimple))
>> >> void foo(void)
>> >> {
>> >> // local decls/initializers in C
>> >> // GIMPLE body
>> >> }
>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>> >> is a GIMPLE function.
>> >
>> > Though instead of an attribute I would indeed use a new keyword (as you
>> > can't really ignore the attribute and it should be an error with compilers
>> > not knowing it). Thus sth like
>> >
>> > void foo (void)
>> > __GIMPLE {
>> > }
>> >
>> > as it's also kind-of a "definition" specifier rather than a
>>
Re: [gimplefe] [gsoc16] Gimple Front End Project
On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
wrote:
> Hi!
>
> How exactly can we achieve start stop compilation on specific pass (ie
> run single pass on input)?
>
> eg. $cgimple -ftree-copyrename foo.c
>
> should produce optimization result of -ftree-copyrename pass on foo.c input
You need pass manager support and annotate each function with information
on what passes should be run (in which order even?). I think for the GSoC
project specifying a starting pass for each function via the source, like
__GIMPLE (tree-copyrename) void foo (void)
{
...
}
and hacking the pass manager to honor that is enough.
Richard.
>
>
> On 21 March 2016 at 09:05, Trevor Saunders wrote:
>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
>>> Hi!
>>>
>>> Sorry for the late reply.
>>>
>>> I was observing gimple dumps and my initial findings are, to parse
>>> gimple, we have to add support for following components to C FE
>>>
>>> *basic blocks
>>
>> I'd think you can probably make these enough like C labels that you
>> don't need to do anything special in the C fe to parse these. Just
>> removing the < and > gets you pretty close is that it?
>>
>>> *gimple labels and goto
>>
>> Similar I think.
>>
>>> *gimple phi functions
>>> iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>
>> yesI think you need to add something here. I think you can do it as a
>> builtin type function that expects its arguments to be labels or names
>> of variables.
>>
>>> *gimple switch
>>> switch (a_1) , case 1: , case 2: >
>>
>> I'd think we could make this more C like too.
>>
>>> *gimple exception handling
>>
>> yeah, though note exceptions are lowered pretty quickly so supporting
>> them with the explicit exception syntax probably isn't particularly
>> important.
>>
>>> *openmp functions like
>>> main._omp_fn.0 (void * .omp_data_i)
>>
>> I'd think you'd want to change the duping of this some to make it easier
>> to tell from struct.some.member.
>>
>>> Please correct me if I am wrong. Also point out if I am missing anything
>>
>> I think you might need to do something about variable names?
>>
>> Trev
>>
>>>
>>>
>>>
>>>
>>> On 18 March 2016 at 14:53, Richard Biener
>>> wrote:
>>> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
>>> > wrote:
>>> >> On 15 March 2016 at 20:46, Richard Biener
>>> >> wrote:
>>> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 10 Mar 2016, Richard Biener wrote:
>>>
>>> > Then I'd like to be able to re-construct SSA without jumping through
>>> > hoops (usually you can get close but if you require copies propagated
>>> > in
>>> > a special way you are basically lost for example).
>>> >
>>> > Thus my proposal to make the GSoC student attack the unit-testing
>>> > problem by doing modifications to the pass manager and "extending" an
>>> > existing frontend (C for simplicity).
>>>
>>> I think it's wrong to try to shoehorn the gimple FE into the C FE. C
>>> is
>>> fundamentally different from gimple and you'd have to sprinkle
>>> gimple_dialect_p() all over the place, and maintaining that while
>>> developing future C improvements will turn out to be much work. Some
>>> differences of C and gimple:
>>>
>>> * C has recursive expressions, gimple is n-op stmts, no expressions at
>>> all
>>> * C has type promotions, gimple is explicit
>>> * C has all other kinds of automatic conversion (e.g. pointer decay)
>>> * C has scopes, gimple doesn't (well, global and local only), i.e.
>>> symbol
>>> lookup is much more complicated
>>> * C doesn't have exceptions
>>> * C doesn't have class types, gimple has
>>> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
>>> * C doesn't have self-referential types
>>> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
>>> gimplifier and again would feed gimple directly into the passes)
>>>
>>> I really don't think changing the C FE to accept gimple is a useful way
>>> forward.
>>> >>>
>>> >>> So I am most worried about replicating all the complexity of types and
>>> >>> decl
>>> >>> parsing for the presumably nice and small function body parser.
>>> >> Um would it be a good idea if we separate "gimple" functions from
>>> >> regular C functions,
>>> >> say by annotating the function definition with "gimple" attribute ?
>>> >
>>> > Yes, that was my idea.
>>> >
>>> >> A "gimple" function should contain only gimple stmts and not C.
>>> >> eg:
>>> >> __attribute__((gimple))
>>> >> void foo(void)
>>> >> {
>>> >> // local decls/initializers in C
>>> >> // GIMPLE body
>>> >> }
>>> >> Or perhaps we could add a new keyword "gimple" telling C FE that this
>>> >> is a GIMPLE function.
>>> >
>>> > Though instead of an attribute I would indeed use a new keyword (as you
>>> > can't really ignore the attribute and it sh
Re: [gimplefe] [gsoc16] Gimple Front End Project
On 22 March 2016 at 16:26, Richard Biener wrote:
> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
> wrote:
>> Hi!
>>
>> How exactly can we achieve start stop compilation on specific pass (ie
>> run single pass on input)?
>>
>> eg. $cgimple -ftree-copyrename foo.c
>>
>> should produce optimization result of -ftree-copyrename pass on foo.c input
>
> You need pass manager support and annotate each function with information
> on what passes should be run (in which order even?). I think for the GSoC
> project specifying a starting pass for each function via the source, like
>
> __GIMPLE (tree-copyrename) void foo (void)
> {
> ...
> }
>
> and hacking the pass manager to honor that is enough.
Um would annotating each function with pass order work for ipa passes too ?
Thanks,
Prathamesh
>
> Richard.
>
>>
>>
>> On 21 March 2016 at 09:05, Trevor Saunders wrote:
>>> On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
Hi!
Sorry for the late reply.
I was observing gimple dumps and my initial findings are, to parse
gimple, we have to add support for following components to C FE
*basic blocks
>>>
>>> I'd think you can probably make these enough like C labels that you
>>> don't need to do anything special in the C fe to parse these. Just
>>> removing the < and > gets you pretty close is that it?
>>>
*gimple labels and goto
>>>
>>> Similar I think.
>>>
*gimple phi functions
iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
>>>
>>> yesI think you need to add something here. I think you can do it as a
>>> builtin type function that expects its arguments to be labels or names
>>> of variables.
>>>
*gimple switch
switch (a_1) , case 1: , case 2: >
>>>
>>> I'd think we could make this more C like too.
>>>
*gimple exception handling
>>>
>>> yeah, though note exceptions are lowered pretty quickly so supporting
>>> them with the explicit exception syntax probably isn't particularly
>>> important.
>>>
*openmp functions like
main._omp_fn.0 (void * .omp_data_i)
>>>
>>> I'd think you'd want to change the duping of this some to make it easier
>>> to tell from struct.some.member.
>>>
Please correct me if I am wrong. Also point out if I am missing anything
>>>
>>> I think you might need to do something about variable names?
>>>
>>> Trev
>>>
On 18 March 2016 at 14:53, Richard Biener
wrote:
> On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> wrote:
>> On 15 March 2016 at 20:46, Richard Biener
>> wrote:
>>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote:
Hi,
On Thu, 10 Mar 2016, Richard Biener wrote:
> Then I'd like to be able to re-construct SSA without jumping through
> hoops (usually you can get close but if you require copies
> propagated in
> a special way you are basically lost for example).
>
> Thus my proposal to make the GSoC student attack the unit-testing
> problem by doing modifications to the pass manager and "extending" an
> existing frontend (C for simplicity).
I think it's wrong to try to shoehorn the gimple FE into the C FE. C
is
fundamentally different from gimple and you'd have to sprinkle
gimple_dialect_p() all over the place, and maintaining that while
developing future C improvements will turn out to be much work. Some
differences of C and gimple:
* C has recursive expressions, gimple is n-op stmts, no expressions
at all
* C has type promotions, gimple is explicit
* C has all other kinds of automatic conversion (e.g. pointer decay)
* C has scopes, gimple doesn't (well, global and local only), i.e.
symbol
lookup is much more complicated
* C doesn't have exceptions
* C doesn't have class types, gimple has
* C doesn't have SSA (yes, I'm aware of your suggestions for that)
* C doesn't have self-referential types
* C FE generates GENERIC, not GIMPLE (so you'd need to go through the
gimplifier and again would feed gimple directly into the passes)
I really don't think changing the C FE to accept gimple is a useful
way
forward.
>>>
>>> So I am most worried about replicating all the complexity of types and
>>> decl
>>> parsing for the presumably nice and small function body parser.
>> Um would it be a good idea if we separate "gimple" functions from
>> regular C functions,
>> say by annotating the function definition with "gimple" attribute ?
>
> Yes, that was my idea.
>
>> A "gimple" function should contain only gimple stmts and not C.
>> eg:
>> __attribute__((gimple))
>> void foo(void)
>> {
>>
Re: [gimplefe] [gsoc16] Gimple Front End Project
On Tue, Mar 22, 2016 at 2:45 PM, Prathamesh Kulkarni
wrote:
> On 22 March 2016 at 16:26, Richard Biener wrote:
>> On Tue, Mar 22, 2016 at 12:08 AM, Prasad Ghangal
>> wrote:
>>> Hi!
>>>
>>> How exactly can we achieve start stop compilation on specific pass (ie
>>> run single pass on input)?
>>>
>>> eg. $cgimple -ftree-copyrename foo.c
>>>
>>> should produce optimization result of -ftree-copyrename pass on foo.c input
>>
>> You need pass manager support and annotate each function with information
>> on what passes should be run (in which order even?). I think for the GSoC
>> project specifying a starting pass for each function via the source, like
>>
>> __GIMPLE (tree-copyrename) void foo (void)
>> {
>> ...
>> }
>>
>> and hacking the pass manager to honor that is enough.
> Um would annotating each function with pass order work for ipa passes too ?
There is no single point of execution for an IPA pass so no - you can
tag it with
one of the umbrella passes I guess. I suppose we'd need some magic "phase"
tags for this, like simply "IPA". You then need to enable/disable IPA passes
you want to run.
Richard.
> Thanks,
> Prathamesh
>>
>> Richard.
>>
>>>
>>>
>>> On 21 March 2016 at 09:05, Trevor Saunders wrote:
On Mon, Mar 21, 2016 at 04:43:35AM +0530, Prasad Ghangal wrote:
> Hi!
>
> Sorry for the late reply.
>
> I was observing gimple dumps and my initial findings are, to parse
> gimple, we have to add support for following components to C FE
>
> *basic blocks
I'd think you can probably make these enough like C labels that you
don't need to do anything special in the C fe to parse these. Just
removing the < and > gets you pretty close is that it?
> *gimple labels and goto
Similar I think.
> *gimple phi functions
> iftmp_0_1 = PHI (ftmp_0_3, iftmp_0_4)
yesI think you need to add something here. I think you can do it as a
builtin type function that expects its arguments to be labels or names
of variables.
> *gimple switch
> switch (a_1) , case 1: , case 2: >
I'd think we could make this more C like too.
> *gimple exception handling
yeah, though note exceptions are lowered pretty quickly so supporting
them with the explicit exception syntax probably isn't particularly
important.
> *openmp functions like
> main._omp_fn.0 (void * .omp_data_i)
I'd think you'd want to change the duping of this some to make it easier
to tell from struct.some.member.
> Please correct me if I am wrong. Also point out if I am missing anything
I think you might need to do something about variable names?
Trev
>
>
>
>
> On 18 March 2016 at 14:53, Richard Biener
> wrote:
> > On Fri, Mar 18, 2016 at 6:55 AM, Prathamesh Kulkarni
> > wrote:
> >> On 15 March 2016 at 20:46, Richard Biener
> >> wrote:
> >>> On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 10 Mar 2016, Richard Biener wrote:
>
> > Then I'd like to be able to re-construct SSA without jumping through
> > hoops (usually you can get close but if you require copies
> > propagated in
> > a special way you are basically lost for example).
> >
> > Thus my proposal to make the GSoC student attack the unit-testing
> > problem by doing modifications to the pass manager and "extending"
> > an
> > existing frontend (C for simplicity).
>
> I think it's wrong to try to shoehorn the gimple FE into the C FE.
> C is
> fundamentally different from gimple and you'd have to sprinkle
> gimple_dialect_p() all over the place, and maintaining that while
> developing future C improvements will turn out to be much work. Some
> differences of C and gimple:
>
> * C has recursive expressions, gimple is n-op stmts, no expressions
> at all
> * C has type promotions, gimple is explicit
> * C has all other kinds of automatic conversion (e.g. pointer decay)
> * C has scopes, gimple doesn't (well, global and local only), i.e.
> symbol
> lookup is much more complicated
> * C doesn't have exceptions
> * C doesn't have class types, gimple has
> * C doesn't have SSA (yes, I'm aware of your suggestions for that)
> * C doesn't have self-referential types
> * C FE generates GENERIC, not GIMPLE (so you'd need to go through the
> gimplifier and again would feed gimple directly into the passes)
>
> I really don't think changing the C FE to accept gimple is a useful
> way
> forward.
> >>>
> >>> So I am most worried about replicating all the complexity of types
>
Re: Mysterious decision in combine
On 03/21/2016 06:31 AM, Dominik Vogt wrote: > Why does it drop the "parallel" and "clobber" in the combination; > is there a way to force combine to keep that? > > Trying 6 -> 7: > Failed to match this instruction: > (set (reg:DI 65) > (and:DI (subreg:DI (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32]) 0) > (const_int 4294901775 [0x000f]))) > > (Because all "and" instructions on s390 clobber the CC, this > pattern does not match anything without the clobber.) The main body of combine doesn't keep them, but when it comes to recognize the new instruction, there's a path through recog that knows how to add them back. See the call to (the generated) add_clobbers function. The real failure is hidden within general_operand: the (subreg:DI (mem:SI ...)) you have there doesn't match. #ifdef INSN_SCHEDULING /* On machines that have insn scheduling, we want all memory reference to be explicit, so outlaw paradoxical SUBREGs. However, we must allow them after reload so that they can get cleaned up by cleanup_subreg_operands. */ if (!reload_completed && MEM_P (sub) && GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (sub))) return 0; #endif Probably what we need is some path through combine that recognizes that bits have already been masked so that we leave the zero-extend alone in places that it makes sense. r~
gcc-5-20160322 is now available
Snapshot gcc-5-20160322 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160322/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 234410 You'll find: gcc-5-20160322.tar.bz2 Complete GCC MD5=07d798c00ae380a5a47cfef3997a96f3 SHA1=91dbf29cd9212c7f68302b72b457e6771330ac9d Diffs from 5-20160315 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Mysterious decision in combine
On Mon, Mar 21, 2016 at 02:31:51PM +0100, Dominik Vogt wrote: > On Thu, Mar 17, 2016 at 01:22:04PM -0700, Richard Henderson wrote: > > On 03/16/2016 11:35 PM, Dominik Vogt wrote: > Now combine tries to combine > > (parallel [ > (set (reg:SI 64) > (and:SI (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32]) > (const_int -65521 [0x000f]))) > (clobber (reg:CC 33 %cc)) > ]) > > and > > (set (reg:DI 65) > (zero_extend:DI (reg:SI 64))) > > Why does it drop the "parallel" and "clobber" in the combination; > is there a way to force combine to keep that? Nope, and it really shouldn't. Combine tries to keep the clobbers that were on the insn that is combined into (your zero_extend), but not the clobbers from all the insns it is integrating. If the resulting insn does not match without clobbers, but would match with clobbers (any clobbers, not just those that were on the original insns) it adds those. [ The "preferably keep clobbers" makes sure that an "add" stays an "add" and isn't turned into a "lea". Many other transforms however do just that anyway; it would be a nice cleanup if combine could just drop the clobbers as well. ] > Trying 6 -> 7: > Failed to match this instruction: > (set (reg:DI 65) > (and:DI (subreg:DI (mem:SI (reg:DI 2 %r2 [ a ]) [1 *a_2(D)+0 S4 A32]) 0) > (const_int 4294901775 [0x000f]))) > > (Because all "and" instructions on s390 clobber the CC, this > pattern does not match anything without the clobber.) As Richard says, the pattern wouldn't match with clobbers included either; if it did, combine would handle this just as you want. Segher
out of bounds access in insn-automata.c
Howdy!
I'm working on enhancements to our out-of-bounds warnings in VRP, such
that we can warn and isolate conditionally out-of-bound accesses
(similar to what we do in gimple-ssa-isolate-paths.c for NULL accesses).
With my WIP I have found the following out of bounds in the array access
at the end of maximal_insn_latency:
int
maximal_insn_latency (rtx insn)
{
int insn_code;
if (insn == 0)
insn_code = DFA__ADVANCE_CYCLE;
else
{
insn_code = dfa_insn_code (as_a (insn));
if (insn_code > DFA__ADVANCE_CYCLE)
return 0;
}
return internal_maximal_insn_latency (insn_code, insn);
}
In the case where insn==0, insn_code is set to the size of
default_latencies[] which will get accessed in the return.
Does insn==0 never happen? Are we reading past the end of
default_latencies[]? What am I missing?
Perhaps we can do:
if (insn == 0) {
gcc_unreachable();
return 1;
}
Or is insn==0? In which case, what should we return?
Aldy
