[cfe-dev] Optimization of arithmetic expressions involving user-defined C++ objects

[Michael Kruse via cfe-dev]

LLVM has its predetermined set of types of instructions
(https://llvm.org/docs/LangRef.html) and optimizations look for
specific instructions that it can be applied to, instead of its
properties. Hence, it is not possible to apply the same optimization
on user-implemented types and operations.

This might change with MLIR which has extendable types and operations
and optimizations might be more guided by an operation property. For
instance, there is mlir::OperationProperty::Commutative so
optimization passes use this property instead of just knowing all the
instructions that are commutative.

Sadly, commutativity is (currently) the only semantic property of
mlir::OperationPropery.

Another item to consider is, once you implemented a custom type and
operators in C++, how does the compiler know about its properties.
There is no C++ API to make the compiler know.

Michael




Am Di., 14. Apr. 2020 um 07:20 Uhr schrieb ardi via cfe-dev
<cfe-dev at lists.llvm.org>:
>
> Hi!
>
> AFAIK, there's no C++ syntax for letting know the compiler that the
> operators in your classes exactly match the same meaning as some
> built-in type. So, if for example you write a class that implements
> IEEE fp math in software, the compiler won't have the chance of
> transforming the expression into a different one that has the same
> result with a lower computation cost (*).
>
> Given that LLVM is hackable by nature, is there some workaround by
> which I could tell clang "consider the operators for this class with
> the same optimization opportunities as this other built-in type" ?
>
> Alternatively, does LLVM have any tool (or do you know of any outside
> LLVM) that would allow to perform static optimization of an arithmetic
> expression and transform the code, similar to a preprocessor step?
>
> (*) Note: I acknowledge that even if the operators had the same
> meaning as a built-in type, maybe their relative cost would be
> different, so, ideally it wouldn't be a matter of just telling the
> meaning of the operator, but also its relative cost.
>
>
> Thanks a lot,
>
> ardi
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev