[Libre-soc-dev] bigint-presentation reg alloc and cranelift's reg alloc

Jacob Lifshay programmerjake at gmail.com
Tue Jan 31 23:28:30 GMT 2023


On Tue, Jan 31, 2023, 15:02 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
>
> On Tuesday, January 31, 2023, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > actually iirc it has since it's a subtask of the fast rsa modular
> exponentiation task.
>
> which has a limited fixed budget and you've been 10+ weeks
> when i anticipated taking around 2-3.
>

yes, i anticipated it taking 4-5 weeks, i ran into unexpected complications.

>
> > the reg alloc experimentation is also quite useful for figuring out how
> SVP64 will be integrated into llvm, gcc, cranelift, etc.
>
> and that should have been discussed *before* going ahead.
>

i figured the experimentation didn't need approval since it's merely a
side-effect of getting the register allocator working in
bigint-presentation-code for rsa.

the usual conversation procedure is:
>
> * i'm thinking of doing x
> * i'm doing x
> * i've done x
>
> and to follow that when changing intention.
>

ok. i figured that wasn't necessarily required since the goals and subtasks
for this haven't changed -- it's still:
rsa: (sorta task list, sorta top-level algorithm)
    done afaict -- toom-cook generates ssa-form algorithm
    todo -- dead code elimination
    wip -- register allocator (translates from ssa-form to physical
registers, merges copies)
    todo -- dead code elimination (shares code with pre-reg-alloc DCE)
    done -- asm generation
    todo -- isacaller simulation (everything up to and including this point
is required by rsa task)
    todo -- simplistic OoO mul pipe simulation (needed for presentation
animation)
    todo -- presentation animation
    todo -- write presentation script
    todo -- record audio
    todo -- render presentation video
    todo -- publish video

there's also pre-asm-generation simulations (can't use isacaller since
there's no asm yet) to ensure my code is correct, those are all done.

>
> finding out a change of direction on *an un-audited* resource
> is alarming.
>

that was coincidental, that readme i linked has been in *our* git repo well
before i ever mentioned rewriting on that zulip chat.

Jacob


More information about the Libre-soc-dev mailing list