[llvm-dev] RFC: Pass for lowering "non-linear" arithmetics of illegal types

[Paweł Bylica via llvm-dev]

No more comments so far, but I have some questions about passes
infrastructure.

Can the pass be implemented for the new pass manager? If yes, will it be
able to be used by the legacy pass manager?

I think the simplest starting point is basic block pass. Can a basic block
pass add new function declarations and/or definitions to the module it runs
on?

If basic block is not an option should it be a module pass that trivially
iterates over all functions and blocks? From my little experience such
passes performed quite badly.

The third option I can think of is some combination of analysis and
transform passes.

- Paweł

On Tue, Oct 6, 2015 at 12:44 AM Paweł Bylica <chfast at gmail.com> wrote:

> On Tue, Oct 6, 2015 at 12:25 AM Tim Northover <t.p.northover at gmail.com>
> wrote:
>
>> On 5 October 2015 at 15:09, Paweł Bylica <llvm-dev at lists.llvm.org> wrote:
>> > The pass replaces instructions mul, udiv, urem, sdiv, srem that are
>> know to
>> > be not supported by target's type legalization with a call to a function
>> > that implements given arithmetic operation.
>>
>> This seems quite sensible, those functions can get bigger than you'd
>> want to inline.
>>
>> > The pass also injects these functions to the module with a weak linkage.
>> > The pass requires a function generator (interface implementation) for
>> mul
>> > and udivrem algorithms for integer types of sizes being powers of 2
>> (i.e.
>> > i128, i256, ...). Replacements for other instructions are created using
>> > these 2 algorithms.
>>
>> This sounds a bit weird though. It seems more natural to make these
>> part of a runtime support library for your language (like compiler-rt
>> is for C).
>>
>
> You are probably right. It makes more sense in general case. I was too
> focused on mine. However, we can have both easily. The generator can return
> either function declaration or function definition.
>
>
>>
>> Cheers.
>>
>> Tim.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151006/f08ce448/attachment.html>