This is an archive of the discontinued LLVM Phabricator instance.

Add isl operator overloads for isl::pw_aff (Try II)
ClosedPublic

Authored by grosser on Apr 11 2018, 1:16 PM.

Details

Summary

Piecewise affine expressions have directly corresponding mathematical
operators. Introduce these operators as overloads as this makes writing
code with isl::pw_aff expressions more directly readable.

We can now write:

A = B + C    instead of    A = B.add(C)

Event Timeline

grosser created this revision.Apr 11 2018, 1:16 PM

Did you consider an NFC tag for the title?

We could also overload !=, ==, +=, -=. *=, /=. Would these be added in a follow-up patch?

include/polly/Support/ISLOperators.h
1

File name has capitalized ISL

13

[serious] Header guard still missing

18

Consider using @{ so doxygen knowns to which functions the comment applies

41

[serious] Use 'long' instead of 'int'. That's what isl::val's ctor takes.

unittests/Isl/IslTest.cpp
350

[serious] The other tests use

std::unique_ptr<isl_ctx, decltype(&isl_ctx_free)> Ctx(isl_ctx_alloc(), &isl_ctx_free);

to not require manual releasing the isl_ctx. The dtors of the pw_aff objects will also be only called at the end of the scop, i.e. /after/ their parent isl_ctx is free'd.

Since you expect users to include the header, the operators should also be declared static.

Meinersbur added inline comments.Apr 11 2018, 1:52 PM
include/polly/Support/ISLOperators.h
110–166

[comment] Using tdiv as basis for division and remainder corresponds to C/C++'s definition of these operators, i.e. the most consistent choice.
However, in practice this rarely what a user really wants, most often it is modulo (cdiv) or they assume that the divisor is positive or divides the dividend in an integer (divexact). Would not defining a default division/remainder operator an option?

grosser updated this revision to Diff 142070.Apr 11 2018, 1:59 PM

Changes since last patch:

  • Capitalize ISL in header comment
  • Add header guards
  • Use "@{" to indicate multi-function doxygen comments
  • Use unique_ptr when allocating isl_ctx
  • Use "static inline"

Since you expect users to include the header, the operators should also be declared static.

This is not required. If the inline-function has external linkage, the compiler/linker may (and even must) reuse the same symbol for all cases where the function is not inlined (which is possible at the compiler's judgment). With static, the same function symbol can appear multiple times in the final executable, resulting in larger executables. This is how I understand http://en.cppreference.com/w/cpp/language/inline

grosser marked 4 inline comments as done.Apr 11 2018, 2:03 PM

Hi Michael, hi Philip.,

thanks for the very helpful comments. I believe I addressed all but the one I comment below explicitly:

include/polly/Support/ISLOperators.h
110–166

Very good analysis. We should either add a comment why these operators are choosen or drop them.

I am open to not having any division / remainder operators defined -- either forever or just as a start. If this is what you want and others agree I can drop this. Is this what you would prefer? Or should I rather add a comment why these have been choosen?r

@Meinersbur , your analysis regarding static seems correct. If @philip.pfaffe agrees, I drop the 'static' keyword again.

Meinersbur accepted this revision.Apr 11 2018, 4:34 PM

@Meinersbur , your analysis regarding static seems correct. If @philip.pfaffe agrees, I drop the 'static' keyword again.

I don't really care. Compilation might faster with static because the compiler does not have to emit those symbols (I'd expect a compiler to not emit the symbols if the function is not used, even with external linkage; because the language mandates that an inline function has a definition in every translation unit, i.e. there is no translation unit that requires the symbol without defining it; it is true for clang, msvc and gcc; I checked. However, only for C++ but not C).

LGTM

include/polly/Support/ISLOperators.h
110–166

I'm fine with keeping them. Probably the most typical use cases are with constant-positive divisors: aff / 2 and aff % 2. We probably want to support this use case and it does not matter what the behavior with negative divisors is.

This revision is now accepted and ready to land.Apr 11 2018, 4:34 PM
grosser updated this revision to Diff 142115.Apr 11 2018, 11:15 PM

Add comments to operator/ and operator% describing that we round towards zero.

grosser updated this revision to Diff 142116.Apr 11 2018, 11:16 PM

Remove unneeded include form incluse/Support/SCEVAffinator

Harbormaster completed remote builds in B17005: Diff 142116.
This revision was automatically updated to reflect the committed changes.