Page MenuHomePhabricator

[InstCombine] Optimize div/ldiv/lldiv

Authored by xbolva00 on Jul 30 2019, 9:34 AM.



Expand function call to pair of sdiv and srem.


Diff Detail

Event Timeline

xbolva00 created this revision.Jul 30 2019, 9:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 30 2019, 9:34 AM

Some general notes:

1, ldiv and lldiv returns agregate, div not - how to solve div case? expand it using shift and or?
2, This looks quite weird for me:

declare { i64, i64 } @ldiv(i64, i64)
declare { i64, i64 } @lldiv(i64, i64)

but this is what I got on Linux Ubuntu OS.
3, Test coverage - if any other tests, please tell me.

xbolva00 updated this revision to Diff 212369.Jul 30 2019, 9:42 AM

Fixed copy paste bug.

xbolva00 updated this revision to Diff 212374.Jul 30 2019, 9:51 AM

Fixed TLI..

Div is returning an i64 because that's the x86-64 ABI. In 32-bit mode I don't think it will return i64.

In fact in 32-bit mode x86. You'll get the return value passed by pointer with the sret attribute for all 3 functions.

Ah yes... That probably complicates many things here...

xbolva00 abandoned this revision.Jul 30 2019, 11:00 AM
xbolva00 reclaimed this revision.Jul 30 2019, 11:20 AM
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.

Can I leave TODO for 32bit versions of div?

What targets does the divl and divll code work for? Definitely doesn't work for arm on linux or i386 on linux. But those are the only ones I checked.

Would it be better to just recognize this as a builtin in clang and just emit the IR instructions?

Would it be better to just recognize this as a builtin in clang and just emit the IR instructions?

This seems like a better approach

If we're going to recognize a C function that returns an aggregate, we need to be very careful that the form we're recognizing is a specific, known pattern. We need to be sure that we're recognizing a specific way of returning an aggregate, and TLI needs an API to tell transforms which specific way it recognized. We don't need to add all the possible patterns in the first patch, of course.

One concern that applies to "div" specifically, which you didn't mention, is that the order of the members of div_t isn't specified in any standard, so we also need an API to get the order on a given target.

It might be better to just handle this in clang, instead of TLI; it would be much easier to do the right thing with an AST that has the original struct type and member names. Or actually, maybe this just isn't worth doing, because the API is rarely used; I tried searching the entire Android tree, and only managed to find a couple uses.

xbolva00 abandoned this revision.Jul 30 2019, 12:09 PM

Yeah, probably not worth to do since it is rarely used (but surprisingly latest MSVC does it)