search for: riyaz

...d setSignedInt and getSignedInt may be OK. Further, sign-extension would need two shift instructions in X86 as opposed to no-sign extension where only one ‘and’ with mask is needed for retrieving the int. From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Wednesday, April 4, 2018 7:43 AM To: Riyaz Puthiyapurayil <Riyaz.Puthiyapurayil at synopsys.com> Cc: Florian Hahn <florian.hahn at arm.com>; llvm-dev <llvm-dev at lists.llvm.org>; nd <nd at arm.com> Subject: Re: [llvm-dev] llvm::PointerIntPair -- is this by design or a bug? I'd suggest someone try fixing this &a...

...here might be code > relying on the existing behavior until there's evidence of it. > > I'd suggest changing the behavior & testing to see if anything breaks - > and if nothing does, moving to the behavior rather than supporting both. > > On Wed, Apr 4, 2018 at 9:27 AM Riyaz Puthiyapurayil < > Riyaz.Puthiyapurayil at synopsys.com> wrote: > >> Rather than “fixing” it, it might be better to support a separate method >> for signed extension. My reasoning is as follows: >> >> >> >> int x = 7; >> >> llvm::PointerIn...

...t> pip; pip.setInt(7); // can be made to fail as the valid range // of signed 3-bit values is [-4:3] The above code does not currently fail and instead fails for pip.setInt arguments with values in [-4:-1] which is actually unexpected and the reason I started this email thread. /Riyaz From: David Zarzycki [mailto:dave at znu.io] Sent: Wednesday, April 4, 2018 11:47 AM To: Reid Kleckner <rnk at google.com> Cc: David Blaikie <dblaikie at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; Riyaz.Puthiyapurayil at synopsys.com; nd <nd at arm.com> Subject: Re:...

...e that there might be code relying on the existing behavior until there's evidence of it. > > I'd suggest changing the behavior & testing to see if anything breaks - and if nothing does, moving to the behavior rather than supporting both. > > On Wed, Apr 4, 2018 at 9:27 AM Riyaz Puthiyapurayil <Riyaz.Puthiyapurayil at synopsys.com <mailto:Riyaz.Puthiyapurayil at synopsys.com>> wrote: > Rather than “fixing” it, it might be better to support a separate method for signed extension. My reasoning is as follows: > > > > int x = 7; > > llvm::...

...amp; not to speculate that there might be code relying on the existing behavior until there's evidence of it. I'd suggest changing the behavior & testing to see if anything breaks - and if nothing does, moving to the behavior rather than supporting both. On Wed, Apr 4, 2018 at 9:27 AM Riyaz Puthiyapurayil < Riyaz.Puthiyapurayil at synopsys.com> wrote: > Rather than “fixing” it, it might be better to support a separate method > for signed extension. My reasoning is as follows: > > > > int x = 7; > > llvm::PointerIntPair<double*, 3, int> pip; > &g...

define dso_local i32 @f(i32 %0) { %2 = and i32 %0, 7 %3 = icmp eq i32 %2, 7 %4 = zext i1 %3 to i32 ret i32 %4 } I thought instcombine would remove it. It doesn't and nothing else does either. LLVM Version is 10.0.0. /Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200612/43c0ad0a/attachment-0001.html>

...air supports signed int types if it always loses the sign. Is it just to avoid signed/unsigned comparison when comparing the return value of getInt with signed types? Or to use enums that default to a signed type? In any case, this should be clearly documented if there is no intention to fix it. / Riyaz On Apr 4, 2018, at 4:04 AM, Florian Hahn <florian.hahn at arm.com<mailto:florian.hahn at arm.com>> wrote: On 04/04/2018 11:15, David Chisnall wrote: On 4 Apr 2018, at 11:01, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:...

I'd suggest someone try fixing this & see if it breaks anything that can't reasonably be fixed (before we go assuming this is by design/shouldn't be fixed just because it's the way it is today). On Wed, Apr 4, 2018 at 7:16 AM Riyaz Puthiyapurayil via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It won't move the sign bit, so negative values won't fit, unless you have > a 3 bit signed type ;) > > > Note that if you assign negative values to and then read from a signed > bit-field, you would...

...for (int i = 0; i < 100; ++i) A[i] = i; return A[10]; } Neither gcc nor clang eliminates the loop. Clang also blows up the code a bit by unrolling the loop. Why can't this loop and the array be eliminated and the function body turned into ret i32 10 ? Am I missing something? /Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200617/b68c2e7c/attachment.html>

...e specifically the following works (declaring before or after the call seems to work in assembly): %a = call i64 (...) @llvm.foobar.i64(i32 %b, i32 %xc) : : declare i64 @llvm.foobar.i64(...) Any comments? How is the call to such an intrinsic supposed to be constructed with IRBuilder? /Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201005/d40d2c2b/attachment.html>

We have been using LLVM 3.4 and are currently migrating to LLVM 3.8.1. We have been using the Old JIT and since it has been removed since 3.6, we have to use MCJIT. I find that run-time performance is very poor in 3.8.1 for the Fibonacci example in llvm/examples/fibonacci.cpp. Logs below for fib34 and fib381 for input values of 30 and 40. I first thought it could be that MCJIT compile time is

...if there is a known change in LLVM or clang to assume that malloc will return > 8 byte aligned memory based on the allocation size or if this has always been the case. I want to know if my program compiled with 3.9.1 also has a problem that was just not exposed in testing. Thanks in advance. /Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/3a0b5781/attachment.html>

Can someone confirm whether the following is a known clang bug? I am having a lot of trouble compiling some old legacy code due to this error. I know "using namespace" is horrible but that doesn't make it illegal (g++ accepts this). The fix is easy but there are just too many instances of this in the legacy code. The following is not from the code I am trying to compile but is

Is there an existing option in X86_64 target code generator to emit a loop for the following code: define i4096 @add(i4096 %a, i4096 %b) alwaysinline { %c = add i4096 %a, %b ret i4096 %c } instead of: movq %rdi, %rax addq 96(%rsp), %rsi adcq 104(%rsp), %rdx movq %rdx, 8(%rdi) movq %rsi, (%rdi) adcq 112(%rsp), %rcx movq %rcx, 16(%rdi) adcq

On 4 Apr 2018, at 11:01, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: >> llvm::PointerIntPair<double*, 3, signed> P; >> P.setInt(-4); >> Ideally, the value range for a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the signed int field in PointerIntPair is behaving...

...f code where one can "correctly" skip initialization. The Briggs-Torczon sparse set data structure comes to mind (where you are not comparing two uninitialized variables but an uninitialized variable with an initialized variable-LLVM seems to do the right thing in that case, though). n Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130816/634f1ba0/attachment.html>

...or a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the signed int field in PointerIntPair is behaving the same as an 3-bit unsigned field which has the legal value range of [0,7]. Is this by design? Are negative values not allowed in PointerIntPair? /Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180404/85ccf480/attachment.html>

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These

On 04/04/2018 11:15, David Chisnall wrote: > On 4 Apr 2018, at 11:01, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On 04/04/2018 05:34, Riyaz Puthiyapurayil via llvm-dev wrote: >>> llvm::PointerIntPair<double*, 3, signed> P; >>> P.setInt(-4); >>> Ideally, the value range for a 3-bit signed integer should be [-4,3]. But the above call to setInt will fail. Essentially, the signed int field in PointerIntPair...

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>