search for: puthiyapurayil

...ignedInt 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 & see if it b...

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

...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::PointerIntPair&...

...tually 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: [llvm-dev] llvm::PointerIntPair -- is this by design or a bug? The sign extension is correct. Otherwise setInt(-1) won’t work. If you don’t want sign extension, then use ‘unsigned’ and not ‘int’ in the template arguments. On Apr 4, 2018, at...

...ot 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; > > pip.setInt(x...

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 do sign extensi...

...rian 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: 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 the same as an 3-bit unsigned field which...

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

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

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:

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 the same as an...

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>

I have a variadic intrinsic that is defined as something like this: def int_foobar : Intrinsic<[llvm_anyint_ty], [llvm_vararg_ty], [IntrNoMem, IntrSpeculatable]>; When I construct a call to the above intrinsic with IRBuilder::CreateIntrinsic, it mangles the intrinsic name with the return type (i64) and the actual argument

Consider the following C code. When it is compiled using clang with ' -O', the assert fires. Gcc seems to do the opposite. #include <assert.h> int main() { unsigned a; // uninitialized! unsigned b = a; assert(b == a); // shouldn't this be always true? return 0; } Would you consider this a LLVM bug? I think GVN is responsible for this. I don't know if it

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

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

I have a file for which clang-7 takes over 2 hours to compile with -O3. For the same file, clang-5 takes less than 2 minutes (which is also high IMHO). I will try to create a test case (but it is pretty simple, it only contains initializations of many arrays of structs where the structs are of the following form: struct Foo { EnumType1 e1; // there are 700+ enum labels std::string s1;

int f() { int A[100]; 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

I have some programs crashing when I upgraded from clang 3.9.1 to clang 4.0.1. Debugging this I found the reason for the crash. This is happening in the following assembly fragment for a piece of code allocating a class object (size: 24 bytes) using operator new and then initializing it: 0x00002aaaafc145f3 <+35>: callq 0x2aaaafdf5f90 <operator new(unsigned long)>