Add the core scheduling model for the Samsung Exynos-M1 (ARMv8-A).
Details
Diff Detail
Event Timeline
Excellent! It's great to see more specific processor tuning like this.
It looks fine to me. Obviously I can't check the actual latencies, but I assume someone from in Samsung has already taken a look at that. I'll let you decide whether to wait for them to comment publicly.
Tim.
Hi Evandro, Thank you very much for your hard work about the scheduling model for Exynos-M1.
This looks good to me.
Just one comment: Last time I checked, if a sched model is missing from even a single instruction, the compiler will complain with incomplete sched model error when using the compiler (building the compiler was OK). So if the finer scheduling model above provides for all the possible instructions, it would be ok. Otherwise "CompleteModel" should be set to false just in case (if not specified, CompleteModel seems to set to true by default).
Once again, it is great to see the actual insns latencies for the Samsung core.
The script utils/schedcover.py can help you with checking if the scheduling model is complete or not. There is a short comment on how to use it.
I suppose that I am to first run TblGen:
llvm-tblgen --gen-subtarget --debug-only=subtarget-emitter -I ~/src/llvm/include -I ~/src/llvm/lib/Target/AArch64 ~/src/llvm/lib/Target/AArch64/AArch64.td 2> /tmp/AArch64.subtarget
And then:
schedcover.py /tmp/AArch64.subtarget ExynosM1Model
Still, I'm not sure what to make of the output. Any pointers, please?
You use it correctly. It gives you an overview of all the instructions and if there is default scheduling info or a model specific scheduling info available. That is all it does.
By not specifying the second argument you get to see all the models, which help to see the problem where MinSeong KIM was referring to. My understanding of that problem is: if for an instruction there is no default and your model does not give model specific scheduling info, but one of the other models does, then running the scheduler with that model will fail with an abort. Unless the model is marked as incomplete.
One such case I know of can be found at https://llvm.org/bugs/show_bug.cgi?id=25145
Let me see if I understood it. Based on this snippet of the output from the command above:
CNTv8i8, WriteV, COPY, , WriteI COPY_TO_REGCLASS, None, CPYi16, WriteV, M1WriteNALU1
There is no M1 model for CNTv8i8. There is no default model for COPY, but there is an M1 model for it. There is both a default and an M1 model for CPYi16.
Is this M1 model incomplete since CNTv8i8 is not modeled? Is the default model incomplete since COPY is not modeled?
Thank you.
Almost. Completeness of a model is a bit more involved than that I think. As far as I know it is fine not to model a certain instruction if you guarantee this instruction in never seen by the scheduler. For example because you lower the instruction. Also the default column does not refer to a 'model' as such, but to the presence of an SchedRW on that particular instruction.
Since I'm tempted to declare this model incomplete to be on the safe side, what are the drawbacks on an incomplete model?
Can I back port this patch to 3.8? I'm aware of the timing of this request, but it's very specific to an AArch64 processor model. Thoughts?
Sorry, I meant to reply to that before. I think it's reasonable to put into release_38. We never claimed to support the M1 before this patch, so the absolute worst case is someone discovers it doesn't work well and goes back to what they'd have done anyway.
Tim.
@t.p.northover, should I let anyone else know about this back-port before committing it?
Thank you.