search for: bakhvalov

...nd this by changing the field type to uint8_t and adding > casts, but I'm not sure whether we want to work around warnings in other > compilers as a matter of policy. > > Anyone else have thoughts on style here? > > Cheers, > Lang. > > On Fri, May 31, 2019 at 10:54 AM Bakhvalov, Denis < > denis.bakhvalov at intel.com> wrote: > >> Hello, >> >> After commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f we have new warning >> but only if compiled with GCC: >> >> In file included from >> /path/to/llvm/include/llvm/ExecutionEngi...

Hi, We have recently encountered incorrect code generation issues and I think it is a SCEVExpander bug exposed by a recent patch to add nuw/nsw flags when generating code for SCEVMulExpr. The test case IR looks like this- %1 = load i16, i16* %arrayidx %2 = and i16 %1, -32768 The SCEV form of %2 is this- (-32768 * (%1 /u -32768))<nuw><nsw> It has both nsw/nuw flags. The signed

...#39; enabled. In addition, LLVM gcc-werror buildbot seems to be offline since May 9th: http://lab.llvm.org:8011/builders/ubuntu-gcc7.1-werror I understand that changing the code to satisfy GCC requirements might not be desired, but I think this is something that we should do. Best regards, Denis Bakhvalov. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190531/3302267b/attachment.html>

...p libcall we want to generate: exp or __exp_finite. The problem is that if the exp call was lowered to llvm intrinsic, linker doesn’t resolve it from my static library in LTO build, because plugin (LLVMgold.so) doesn’t report those symbols (yet in intrinsic form) to the linker. Best regards, Denis Bakhvalov. -------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiad...

+pcc for thoughts On Fri, Mar 23, 2018 at 9:37 AM, Bakhvalov, Denis <denis.bakhvalov at intel.com > wrote: > Hello Teresa, > > > > > Without -flto, a.o ends up with a reference to __exp_finite, > > That’s correct. > > > > > which also would not be satifisfied out of libexp.a. > > That’s not correct. Even if...

...n-exp) here – > this solves the LTO issue as there will no longer be an llvm intrinsic in the bitcode Yes, I just tested it and -fno-builtin helps in this case. I added definition of __exp_finite to libexp.a and now it was resolved from libexp.a (because no llvm intrinsics). Best regards, Denis Bakhvalov. -------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Ta wiad...

...dUserWithinLoop(L, Inst)) Note, there is another bug opened for the mentioned patch: https://bugs.llvm.org/show_bug.cgi?id=39673, but it only fixes the problem when the SCEV expression type is constant. I'm not opening a new bug yet, but rather want to hear your comments. Best regards, Denis Bakhvalov. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190325/268e5abb/attachment.html>

Hi, I'm using clang frontend. I'm interested in some particular hot loop in my code and I emit a report from vectorizer optimizations passes. I receive nice output if passing -Rpass* flags as long as I'm building without LTO? But with -flto it just prints nothing. Is there a way to emit opt reports when using LTO? For now I can only approximate about whether my the loop will be

...or -fno-builtin-exp etc? That results in a reference to __exp_finite in the .o bitcode (which of course has the same issue I mentioned above, but is consistent). That seems to be the option you should use here when you want to use your own implementations. Teresa On Fri, Mar 23, 2018 at 8:39 AM, Bakhvalov, Denis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Dear community, > > > > Recently I discovered that llvm gold linker plugin (LLVMgold.so) doesn't > add llvm instrinsics symbols to the linker symbol table. I do not claim > that something is necessary wrong,...

...so trivial to report symbols that correspond to llvm intrinsics because we don't know for sure to which exact symbols they will be expanded. For example, in rL322087 we started lowering llvm.exp.* to "__exp_finite" if -ffast-math (or -Ofast) is provided. Any thoughts on this? -Denis Bakhvalov Employee of Intel, compiler development team. -------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-...

Hello, I've been playing around with the really simple example of not cache friendly loop like this: #define N 100 void foo(int** __restrict__ a, int** __restrict__ b) { for (int i = 0; i < N; ++i) for (int j = 0; j < N; ++j) a[j][i] += b[j][i]; } link to compiler explorer:

Hi Denis, On Fri, Jul 19, 2019 at 6:55 AM Bakhvalov, Denis <denis.bakhvalov at intel.com> wrote: > Hello Rui, all, > > We recently went through the LLD renaming process at Intel and it went > reasonably well too. > Very glad to hear that! > However I encountered one case when the tool seems not to work: > > > &gt...

Dear community, I was wondering how exactly clang/llvm handles undefined behavior (UB). Because of this experiment: https://godbolt.org/g/cEmGHa, I tend to think that clang is light-weight in this subject and does not detect UB. And all the optimizations related to UB are done in llvm via some optimization pass (passes). Is it so? If so than what is the name of that pass? And do different

Hi Rui, all, Yesterday I brought the variable-renaming commits in to Sony's downstream LLD. We have a merge-based flow rather than continually rebasing our patch set, but it went reasonably smoothly nevertheless. The one snag I hit is that the tool initially missed variables mentioned in assert()s. I didn't put much time in to investigating this, but I presume it's because my