search for: guinet

> 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...

The next LLVM social in Paris will happen on January 30th, 2018. Everyone interested in LLVM, Clang, lldb, Polly, lld, ... is invited to join. Event details, including registration (free but mandatory) at http://www.meetup.com/LLVM-Clang-social For this meetup, Adrien Guinet, Serge Guelton and Juan Manuel Martinez will talk about the "Challenges when building an LLVM bitcode obfuscator", based on their 4 years experience building an industrial strength code obfuscator for C/C++ and Objective C. Looking forward to meet you ! -- Arnaud de Grandmaison, Duncan S...

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. For instance, for now, the x86 & aarch64 backend generate constant time code for additions on i256 integers (see https://godbolt.org/z/xMfkqz & https://godbolt.org/z/jbkSpe), but is there

...timately) consider inttoptr/ptrtoint as no-op, and does not handle them. The thing is that, in our case, the GEP in %23 is thus not analyzed by SCEV, and the PHI %16 is thus not considered as an induction variable. To confirm this hypothesis, I created a small out-of-tree pass (https://github.com/aguinet/llvm-intptrcleanup) which registers before loop vectorization and does the following: * first, it search for phi nodes who have those properties: - every incoming value of the phi node is a ptrtoint instruction. The original pointer type of every ptrtoint instruction must be the same type T. -...

On 06/20/2017 03:26 AM, Hal Finkel wrote: > Hi, Adrien, Hello Hal! Thanks for your answer! > Thanks for reporting this. I recommend that you file a bug report at > https://bugs.llvm.org/ Will do! > Whenever I see reports of missed optimization opportunities in the face > of ptrtoint/inttoptr, my first question is: why are these instructions > present in the first place? At

Hello everyone, I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute (https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098), to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes (e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi" attribute. In this mail, I will describe why we woul...

On 5/18/20 8:24 PM, Craig Topper wrote: > I can tell you that your avx512 issue is that v64i8 gfni instructions also > require avx512bw to be enabled to make v64i8 a supported type. The C > intrinsics handling in the front end know this rule. But since you > generated your own intrinsics you bypassed that. Indeed that's the issue... I was stick with what Intel announces here

...nterested. Please send any tips or feedback to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. ## News and articles from around the web Reminder: the deadline for paper submissions for [EuroLLVM 2018](http://llvm.org/devmtg/2018-04/) is this Friday, February 9th. Adrien Guinet has released [DragonFFI](https://github.com/aguinet/dragonffi/), a C Foreign Function Interface (FFI) library based on Clang/LLVM. It aims to provide broader ABI support than libffi and to work around the limitations of Python's cffi C parser through the use of Clang. ## On the mailing lists...

Hi, I am new to llvm with a particular interested in the optimization area, specially on SLP. While working through the tutorial, I ran this example [1] with the hope to see SLP vectorization in action but for some reason, I do not see it on the LLVM assembly as seen below. Is there anything I am missing? I am using Clearlinux as build machine and this has clang version 9.0.0.

...715923615551520, i64 undef> to <16 x i8>), i8 -86) %2 = extractelement <16 x i8> %1, i64 0 ret i8 %2 } (if that's profitable, which might not be the case here, see below) Another more interesting example where we could see potential benefits is this one: https://github.com/aguinet/llvm-project/commit/9ed424cbac0fe3566f801167e2190fad5ad07507#diff-21dd247f3b8aa49860ae8122fe3ea698R22 This gets even more interesting with vectorized code, with an example here: * original C code: https://pastebin.com/4JjF7DPu * LLVM IR after clang -O2 -mgfni -mavx2: https://pastebin.com/Ti0Vm2gj...