Displaying 20 results from an estimated 4000 matches similar to: "Why doesn't this loop get removed?"
2018 Apr 04
2
llvm::PointerIntPair -- is this by design or a bug?
I'd argue that bitfield sign extensions are surprising and are usually a
source of bugs. It would be much more explicit and less error prone for the
user to write the sign extension if they want it.
By extension, it seems good that PointerIntPair doesn't do sign extension
when the type happens to be signed.
On Wed, Apr 4, 2018 at 9:47 AM David Blaikie via llvm-dev <
llvm-dev at
2018 Apr 05
1
llvm::PointerIntPair -- is this by design or a bug?
I do agree that sign-extension is the right thing to do. Unlike bit-fields, llvm::PointerIntPair has asserts checking that the int value is within range. So if you assign an out of range value, it should fail with an assertion:
llvm::PointerIntPair<SomeType*, 3, int> pip;
pip.setInt(7); // can be made to fail as the valid range
// of signed 3-bit values is [-4:3]
The above
2018 Apr 04
0
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 14:34, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> I'd argue that bitfield sign extensions are surprising and are usually a source of bugs. It would be much more explicit and
2018 Apr 04
3
llvm::PointerIntPair -- is this by design or a bug?
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);
There could be code out there that expects pip.getInt() to return 7 and not -1.
So if you really want to set a negative and return a negative value, a separate method setSignedInt and getSignedInt
2018 Apr 04
0
llvm::PointerIntPair -- is this by design or a bug?
I think it'd be reasonable to model this on the same behavior as int to
short to int round-tripping & 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
2020 Jun 12
3
Why doesn't this `and` get eliminated
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:
2018 Apr 04
0
llvm::PointerIntPair -- is this by design or a bug?
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,
2018 Apr 04
2
llvm::PointerIntPair -- is this by design or a bug?
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 extension. So 3-bit signed types do exist in C++.
It begs the question why PointerIntPair supports signed int types if it always loses the sign. Is it just to avoid signed/unsigned comparison
2020 Oct 05
2
Question about using IRBuilder::CreateIntrinsic for a variadic intrinsic
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
2018 Apr 04
2
llvm::PointerIntPair -- is this by design or a bug?
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
2013 Aug 16
1
[LLVMdev] Uninitialized variables -- LLVM bug?
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
2018 Apr 04
2
llvm::PointerIntPair -- is this by design or a bug?
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
2017 Oct 02
5
SSE instructions and alignment of the return value of 'new'
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)>
2020 Aug 23
3
clang performing worse than gcc for this loop
I am analyzing a clang 10.0.0 vs gcc 7.3 performance difference that I can reproduce in the following test.
unsigned foo(unsigned t1, unsigned t2, int count, int step) {
unsigned tmp = 0;
int state = 0;
for (int i = 0 ; i < count ; i += step) {
state++;
if (state > 5)
state = 0;
if (state == 3)
tmp += t2;
}
return tmp;
}
2013 Sep 19
3
[LLVMdev] extern "C" and namespaces
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
2018 Apr 04
0
llvm::PointerIntPair -- is this by design or a bug?
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
2018 Apr 04
0
llvm::PointerIntPair -- is this by design or a bug?
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 has the
2020 Aug 17
3
Code generation option for wide integers on x86_64?
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
2017 Oct 07
2
Bug 20871 -- is there a fix or work around?
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
2016 Jun 10
2
MCJIT -- Poor run-time performance for Fibonacci example in LLVM 3.8.1
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