[llvm-dev] _ExtInt, LLVM integers and constant time
Roman Lebedev via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 22 09:57:17 PDT 2020
On Wed, Apr 22, 2020 at 7:35 PM Adrien Guinet <aguinet at quarkslab.com> wrote:
> On 4/22/20 6:13 PM, Chris Lattner wrote:>> On Apr 22, 2020, at 12:24 AM, Roman Lebedev via
> llvm-dev <llvm-dev at lists.llvm.org>
> >> wrote:
> >> On Wed, Apr 22, 2020 at 9:35 AM Adrien Guinet via llvm-dev <llvm-dev at lists.llvm.org
> >> <mailto:llvm-dev at lists.llvm.org>> wrote:
> >>> Hello everyone,
> >>> After reading the nice blog post about _ExtInt, I was wondering whether operations
> >>> on i128/i256 and more generally on integer types in LLVM are guaranteed to be
> >>> constant time or not.
> >> I don't believe there's any such guarantee even for normal 8/16/32/64 -bit integers.
> > Right. I would expect this to be implementation / target dependent. The maximum bit
> > width of an integer may also be target specific. For example, some targets may not
> > provide a 1024 bit integer divide lib call, and may not want to open code it.
> Okay that makes sense!
> If we would like, at some point, to introduce such guarantees, that would imply adding a
> "constant time" flag to the arithmetic operations at the LLVM IR level,
I don't think that will work. Normally, flags on instructions are
that can be freely dropped without affecting correctness. It's not going to be
really possible to ensure that every single existing&future fold
respects optional correctness-affecting flag.. I suspect this will involve
the similar approach as with constrained floating-point intrinsic.
> and have the
> backends honor it (which already seems the case), or fail if not possible ? .
I think so, yes.
> The only use case I have in mind that would benefit from this is cryptographic code, but
> there might be others.
>From previous discussions on the subject of constant time, i think
has/is involved with some C++ paper about this.
More information about the llvm-dev