Displaying 20 results from an estimated 112 matches for "zeroext".
2014 Dec 26
3
[LLVMdev] Correct usage of `llvm.assume` for loop vectorization alignment?
...e` into the loop body?
v/r,
Josh
[1]
http://llvm.org/devmtg/2014-10/Slides/Finkel-IntrinsicsMetadataAttributes.pdf
[2]
; ModuleID = 'align.ll'
%u8XY = type { i32, i32, i32, i32, i32, i32, [0 x i8] }
; Function Attrs: noduplicate nounwind readonly
declare noalias %u8XY* @likely_new(i32 zeroext, i32 zeroext, i32 zeroext,
i32 zeroext, i32 zeroext, i8* noalias nocapture) #0
; Function Attrs: nounwind
declare void @llvm.assume(i1) #1
; Function Attrs: nounwind
define %u8XY* @benchmark(%u8XY*) #1 {
entry:
%1 = getelementptr inbounds %u8XY* %0, i64 0, i32 3
%columns = load i32* %1, align...
2011 Mar 16
0
[LLVMdev] Calls to functions with signext/zeroext return values
...>
> // FIXME: C calling convention requires the return type to be promoted
> // to at least 32-bit. But this is not necessary for non-C calling
> // conventions. The frontend should mark functions whose return values
> // require promoting with signext or zeroext attributes.
> if (ExtendKind != ISD::ANY_EXTEND && VT.isInteger()) {
> EVT MinVT = TLI.getRegisterType(*DAG.getContext(), MVT::i32);
> if (VT.bitsLT(MinVT))
> VT = MinVT;
> }
>
> There have been a few discussions about this sn...
2007 Nov 23
1
[LLVMdev] Will any pass change simple return branch into select/return pair?
Hi,
Can any llvm pass change simple return branch into select/return pair?
For example:
define i10 @mod_N(i10 zeroext %a) zeroext {
entry:
%tmp2 = icmp ugt i10 %a, -400 ; <i1> [#uses=1]
br i1 %tmp2, label %cond_true, label %return
cond_true: ; preds = %entry
%tmp5 = add i10 %a, 400 ; <i10> [#uses=1]
ret i10 %tmp5
return: ; preds = %entry
ret i10 %a
}
Changed...
2011 Mar 16
3
[LLVMdev] Calls to functions with signext/zeroext return values
...is this bit of code:
// FIXME: C calling convention requires the return type to be promoted
// to at least 32-bit. But this is not necessary for non-C calling
// conventions. The frontend should mark functions whose return values
// require promoting with signext or zeroext attributes.
if (ExtendKind != ISD::ANY_EXTEND && VT.isInteger()) {
EVT MinVT = TLI.getRegisterType(*DAG.getContext(), MVT::i32);
if (VT.bitsLT(MinVT))
VT = MinVT;
}
There have been a few discussions about this snippet on llvmdev in the
past[1...
2011 Mar 16
2
[LLVMdev] Calls to functions with signext/zeroext return values
On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote:
> Promoting the return value is unsafe for bool returns on x86-64, which in the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit register are 0.
My comment is a bit off, because the question of what type to make the return value is somewhat orthogonal to the question of which zext assert we should add.
Cameron
2011 Mar 16
0
[LLVMdev] Calls to functions with signext/zeroext return values
...he ABI only guarantees that the top 7 bits of
>> the 8-bit register are 0.
>
> My comment is a bit off, because the question of what type to make
> the return value is somewhat orthogonal to the question of which zext
> assert we should add.
I'm not sure I follow. Won't a zeroext attribute on a bool return
value ensure that it will be zero-extended to 32 bits by the callee?
Or does the X86 backend consider such functions unlowerable (via
TargetLowering::CanLowerReturn()) and thereby bypass the extension to
32 bits in SelectionDAGBuilder::visitRet() making a promotion in the...
2020 May 15
2
Issues with new Attributor (replaceAllUses fails with type mismatch)
...------------------------------------------------------------------------------------------------------------------------
Sample situation 2:
Original code in IR -- %63 = tail call %struct.cv* bitcast (%struct.cv.231* (i8, i64, i32*)* @Perl_find_runcv_where to %struct.cv* (i8, i64, i32*)*)(i8 zeroext 1, i64 %62, i32* null) #14
Attribute info ---- attributes #14 = { nounwind }
Debug info:
OldCB --- %63 = tail call %struct.cv.231* @Perl_find_runcv_where(i8 zeroext 1, i64 %62) #14
NewCB ---%64 = tail call %struct.cv* bitcast (%struct.cv.231* (i8, i64, i32*)* @15 to %struct.cv* (i8, i64, i32*)*)...
2012 Oct 22
4
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
So, I'm not really sure if this is the right approach. I'd like some
folks from the LLVM side of things to chime in.
In general, I'm not certain we want to continue growing our dependence
on the signext and zeroext attributes on return types, or whether we
want to do the extension in the frontend instead.
Most of the targets in Clang currently eagerly zext or sext the return
value to make it conform to the ABI. You can look at some of the other
classify*Type methods in Clang for how.
On Mon, Oct 22, 2012 at...
2020 May 15
2
Issues with new Attributor (replaceAllUses fails with type mismatch)
...--------------------------------------------------------------------------------------------------
>
>
> Sample situation 2:
>
> Original code in IR -- %63 = tail call %struct.cv* bitcast (%struct.cv.231* (i8, i64, i32*)* @Perl_find_runcv_where to %struct.cv* (i8, i64, i32*)*)(i8 zeroext 1, i64 %62, i32* null) #14
> Attribute info ---- attributes #14 = { nounwind }
>
> Debug info:
> OldCB --- %63 = tail call %struct.cv.231* @Perl_find_runcv_where(i8 zeroext 1, i64 %62) #14
> NewCB ---%64 = tail call %struct.cv* bitcast (%struct.cv.231* (i8, i64, i32*)* @15 to %stru...
2012 Oct 22
0
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
...Chandler Carruth <chandlerc at google.com> wrote:
> So, I'm not really sure if this is the right approach. I'd like some
> folks from the LLVM side of things to chime in.
>
> In general, I'm not certain we want to continue growing our dependence
> on the signext and zeroext attributes on return types, or whether we
> want to do the extension in the frontend instead.
>
> Most of the targets in Clang currently eagerly zext or sext the return
> value to make it conform to the ABI. You can look at some of the other
> classify*Type methods in Clang for how....
2010 Jan 28
3
[LLVMdev] llvm interpreter cannot execute llvm-gcc generated bitcode
...---------
Which generates following llvm assembly:
----------
; ModuleID = 'a.o'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-mingw32"
define i32 @f(i8 zeroext %x) nounwind readnone noinline {
entry:
%0 = zext i8 %x to i32 ; <i32> [#uses=1]
%1 = add i32 %0, -1 ; <i32> [#uses=1]
ret i32 %1
}
define i32 @main() nounwind readnone {
entry:
%0 = tail call i32 @f(i8 zeroext 1) nounwind...
2016 Jul 01
0
Path condition propagation
...1
[dannyb at dannyb-macbookpro3 18:39:22] ~/sources/llvm
(git-svn)-[newgvn-predicates]- :) $ debug-build/bin/llvm-dis greater.bc
[dannyb at dannyb-macbookpro3 18:39:24] ~/sources/llvm
(git-svn)-[newgvn-predicates]- :) $ cat greater.ll
; Function Attrs: norecurse nounwind readnone ssp uwtable
define zeroext i1 @func(i32, i32, i1 zeroext) #0 {
ret i1 true
}
opt -simplifycfg -instcombine does the same thing to it if you use -O0 with
clang
>
I believe this is because LLVM does not recognize that meeting path
> conditions like, for example, X && Y logically means that X is true and Y
&...
2016 Jul 01
3
Path condition propagation
Hi all,
Consider this C code:
#include <stdbool.h>
bool func(int n1, int n2, bool b) {
bool greater = n1 > n2;
if (greater && b) {
if (n1 == n2) {
return false; // unreachable
}
}
return true;
}
The line marked unreachable cannot be reached, however currently LLVM does not optimize it out. I believe this is because LLVM does not
2013 Jan 18
2
[LLVMdev] Weird volatile propagation ?
...:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
%struct.R = type { i16, i16 }
@addr = constant %struct.R* inttoptr (i64 416 to %struct.R*), align 8
define void @test(i16 zeroext %a) nounwind uwtable {
%r.sroa.0 = alloca i16, align 2
%r.sroa.1 = alloca i16, align 2
store i16 %a, i16* %r.sroa.0, align 2
store i16 1, i16* %r.sroa.1, align 2
%r.sroa.0.0.load3 = load volatile i16* %r.sroa.0, align 2
store volatile i16 %r.sroa.0.0.load3, i16* inttoptr (i64 416 to i16...
2019 Sep 26
2
Optimizing functions using logical operators
...the LLVM source code?
Thanks.
bool t1(int v1)
{
return (2 + v1) == 7;
}
bool t2(float v1)
{
return (2.f + v1) == 7.f;
}
bool t3(int v1)
{
return (2 * v1) > 0;
}
bool t4(float v1)
{
return (2.f * v1) > 0;
}
; Function Attrs: norecurse nounwind readnone ssp uwtable
define zeroext i1 @_Z2t1i(i32) #0 {
%2 = icmp eq i32 %0, 5
ret i1 %2
}
; Function Attrs: norecurse nounwind readnone ssp uwtable
define zeroext i1 @_Z2t2f(float) #0 {
%2 = fadd float %0, 2.000000e+00
%3 = fcmp oeq float %2, 7.000000e+00
ret i1 %3
}
; Function Attrs: norecurse nounwind readnone ssp uwt...
2013 Mar 25
1
[LLVMdev] Debug metadata after simplifications
...lly, using the following testcase:
while (while_test()) {
if (if_test()) {
foo();
} else {
bar();
}
}
... Clang emits* the following IR:
*after slightly modifying the code generator so that it also emits
metadata for unconditional branches
while.cond:
%call = call zeroext i1 (...)* @while_test(), !dbg !8
br i1 %call, label %while.body, label %while.end, !dbg !8
while.body:
%call1 = call zeroext i1 (...)* @if_test(), !dbg !9
br i1 %call1, label %if.then, label %if.else, !dbg !9
if.then:
call void (...)* @foo(), !dbg !11
br label %if.end, !dbg...
2016 Jul 01
3
Path condition propagation
...okpro3 18:39:22] ~/sources/llvm
> (git-svn)-[newgvn-predicates]- :) $ debug-build/bin/llvm-dis greater.bc
> [dannyb at dannyb-macbookpro3 18:39:24] ~/sources/llvm
> (git-svn)-[newgvn-predicates]- :) $ cat greater.ll
> ; Function Attrs: norecurse nounwind readnone ssp uwtable
> define zeroext i1 @func(i32, i32, i1 zeroext) #0 {
> ret i1 true
> }
>
>
> opt -simplifycfg -instcombine does the same thing to it if you use -O0
> with clang
>
>>
>
> I believe this is because LLVM does not recognize that meeting path
>> conditions like, for example, X &a...
2012 Oct 23
2
[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values
...;chandlerc at google.com> wrote:
>> So, I'm not really sure if this is the right approach. I'd like some
>> folks from the LLVM side of things to chime in.
>>
>> In general, I'm not certain we want to continue growing our dependence
>> on the signext and zeroext attributes on return types, or whether we
>> want to do the extension in the frontend instead.
>>
>> Most of the targets in Clang currently eagerly zext or sext the return
>> value to make it conform to the ABI. You can look at some of the other
>> classify*Type method...
2010 Jan 28
0
[LLVMdev] llvm interpreter cannot execute llvm-gcc generated bitcode
...ing llvm assembly:
> ----------
> ; ModuleID = 'a.o'
> target datalayout =
> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
> target triple = "i386-mingw32"
>
> define i32 @f(i8 zeroext %x) nounwind readnone noinline {
> entry:
> %0 = zext i8 %x to i32 ;<i32> [#uses=1]
> %1 = add i32 %0, -1 ;<i32> [#uses=1]
> ret i32 %1
> }
>
> define i32 @main() nounwind readnone {
> entry:
>...
2011 Feb 07
2
[LLVMdev] Promoting i16 load to i32
..., MVT::i16, Promote);
setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Promote);
setLoadExtAction(ISD::SEXTLOAD, MVT::i16, Promote);
The DataLayout is "e-p:32:32:32-i8:8:8-i16:32:32-i32:32:32-n32"
If I test with a simple function as the following (which adds two i16
arguments):
define zeroext i16 @a(i16 zeroext %x, i16 zeroext %y) nounwind {
entry:
%x.addr = alloca i16, align 2
%y.addr = alloca i16, align 2
store i16 %x, i16* %x.addr, align 2
store i16 %y, i16* %y.addr, align 2
%tmp = load i16* %x.addr, align 2
%conv = zext i16 %tmp to i32
%tmp1 = load i16* %y.addr, align...