Failure handling half type

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Failure handling half type

Alessio Giovanni Baroni
Hi,

if I write the following simple program:

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16: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"

define void @foo () {
    %1 = alloca half
    store half 0xH42CC, half* %1   ; 0xH42CC = 3.4
    %2 = load half* %1
    ret void
}

llc goes in SIGABRT. In the reference manual says that it's  correct syntax.

It's a bug?

Thanks.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Failure handling half type

Jim Grosbach
Make sure you’re running LLVM with assertions enabled. You’ll get more information about what’s going wrong that way.

That said, yes, this looks like a bug. Specifically, SelectionDAGLegalize::ExpandConstantFP() assumes that f32 is the smallest floating point constant type it’ll need to handle, and that MVT enum ordering reflects that.

  while (SVT != MVT::f32) {                                                      
    SVT = (MVT::SimpleValueType)(SVT.getSimpleVT().SimpleTy - 1); 
    ...
  }

That function, and possibly others, need to be taught how to handle half-floats, it looks like.

-Jim

On Jun 17, 2013, at 6:59 AM, Alessio Giovanni Baroni <[hidden email]> wrote:

Hi,

if I write the following simple program:

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16: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"

define void @foo () {
    %1 = alloca half
    store half 0xH42CC, half* %1   ; 0xH42CC = 3.4
    %2 = load half* %1
    ret void
}

llc goes in SIGABRT. In the reference manual says that it's  correct syntax.

It's a bug?

Thanks.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Failure handling half type

Alessio Giovanni Baroni
Here there is the dump:

SelectionDAG.cpp:81: static bool llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, const llvm::APFloat &): Assertion `VT.isFloatingPoint() && "Can only convert between FP types"' failed.
0  libLLVMSupport.so      0x00007f7405022de5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37
1  libLLVMSupport.so      0x00007f74050232e3
2  libpthread.so.0        0x00007f7404960cb0
3  libc.so.6              0x00007f7403bba425 gsignal + 53
4  libc.so.6              0x00007f7403bbdb8b abort + 379
5  libc.so.6              0x00007f7403bb30ee
6  libc.so.6              0x00007f7403bb3192
7  libLLVMSelectionDAG.so 0x00007f7408266500 llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, llvm::APFloat const&) + 320
8  libLLVMSelectionDAG.so 0x00007f74081df6cf
9  libLLVMSelectionDAG.so 0x00007f74081d12b1
10 libLLVMSelectionDAG.so 0x00007f74081cff57 llvm::SelectionDAG::Legalize() + 375
11 libLLVMSelectionDAG.so 0x00007f74082d6604 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3700
12 libLLVMSelectionDAG.so 0x00007f74082d4f07 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 6455
13 libLLVMSelectionDAG.so 0x00007f74082d2876 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1318
14 libLLVMCodeGen.so      0x00007f74074885dd llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 125
15 libLLVMCore.so         0x00007f740583e2ac llvm::FPPassManager::runOnFunction(llvm::Function&) + 364
16 libLLVMCore.so         0x00007f740583e52b llvm::FPPassManager::runOnModule(llvm::Module&) + 59
17 libLLVMCore.so         0x00007f740583e8d7 llvm::MPPassManager::runOnModule(llvm::Module&) + 519
18 libLLVMCore.so         0x00007f740583ef6b llvm::PassManagerImpl::run(llvm::Module&) + 539
19 libLLVMCore.so         0x00007f740583f0da llvm::PassManager::run(llvm::Module&) + 10
20 llc                    0x000000000040839c
21 libc.so.6              0x00007f7403ba576d __libc_start_main + 237
22 llc                    0x0000000000406d7d
Stack dump:
0.    Program arguments: llc -asm-verbose -filetype=asm -o qwe.S qwe.ll
1.    Running pass 'Function Pass Manager' on module 'qwe.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo'


A small note: this is LLVM 3.3 final linked with libc++ on Ubuntu Linux 12.10.


2013/6/17 Jim Grosbach <[hidden email]>
Make sure you’re running LLVM with assertions enabled. You’ll get more information about what’s going wrong that way.

That said, yes, this looks like a bug. Specifically, SelectionDAGLegalize::ExpandConstantFP() assumes that f32 is the smallest floating point constant type it’ll need to handle, and that MVT enum ordering reflects that.

  while (SVT != MVT::f32) {                                                      
    SVT = (MVT::SimpleValueType)(SVT.getSimpleVT().SimpleTy - 1); 
    ...
  }

That function, and possibly others, need to be taught how to handle half-floats, it looks like.

-Jim

On Jun 17, 2013, at 6:59 AM, Alessio Giovanni Baroni <[hidden email]> wrote:

Hi,

if I write the following simple program:

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16: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"

define void @foo () {
    %1 = alloca half
    store half 0xH42CC, half* %1   ; 0xH42CC = 3.4
    %2 = load half* %1
    ret void
}

llc goes in SIGABRT. In the reference manual says that it's  correct syntax.

It's a bug?

Thanks.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Failure handling half type

Keno Fischer-2
Just ran into this as well. Did you ever open a a bug report about it?


On Tue, Jun 18, 2013 at 3:43 AM, Alessio Giovanni Baroni <[hidden email]> wrote:
Here there is the dump:

SelectionDAG.cpp:81: static bool llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, const llvm::APFloat &): Assertion `VT.isFloatingPoint() && "Can only convert between FP types"' failed.
0  libLLVMSupport.so      0x00007f7405022de5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37
1  libLLVMSupport.so      0x00007f74050232e3
2  libpthread.so.0        0x00007f7404960cb0
3  libc.so.6              0x00007f7403bba425 gsignal + 53
4  libc.so.6              0x00007f7403bbdb8b abort + 379
5  libc.so.6              0x00007f7403bb30ee
6  libc.so.6              0x00007f7403bb3192
7  libLLVMSelectionDAG.so 0x00007f7408266500 llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, llvm::APFloat const&) + 320
8  libLLVMSelectionDAG.so 0x00007f74081df6cf
9  libLLVMSelectionDAG.so 0x00007f74081d12b1
10 libLLVMSelectionDAG.so 0x00007f74081cff57 llvm::SelectionDAG::Legalize() + 375
11 libLLVMSelectionDAG.so 0x00007f74082d6604 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3700
12 libLLVMSelectionDAG.so 0x00007f74082d4f07 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 6455
13 libLLVMSelectionDAG.so 0x00007f74082d2876 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1318
14 libLLVMCodeGen.so      0x00007f74074885dd llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 125
15 libLLVMCore.so         0x00007f740583e2ac llvm::FPPassManager::runOnFunction(llvm::Function&) + 364
16 libLLVMCore.so         0x00007f740583e52b llvm::FPPassManager::runOnModule(llvm::Module&) + 59
17 libLLVMCore.so         0x00007f740583e8d7 llvm::MPPassManager::runOnModule(llvm::Module&) + 519
18 libLLVMCore.so         0x00007f740583ef6b llvm::PassManagerImpl::run(llvm::Module&) + 539
19 libLLVMCore.so         0x00007f740583f0da llvm::PassManager::run(llvm::Module&) + 10
20 llc                    0x000000000040839c
21 libc.so.6              0x00007f7403ba576d __libc_start_main + 237
22 llc                    0x0000000000406d7d
Stack dump:
0.    Program arguments: llc -asm-verbose -filetype=asm -o qwe.S qwe.ll
1.    Running pass 'Function Pass Manager' on module 'qwe.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo'


A small note: this is LLVM 3.3 final linked with libc++ on Ubuntu Linux 12.10.


2013/6/17 Jim Grosbach <[hidden email]>
Make sure you’re running LLVM with assertions enabled. You’ll get more information about what’s going wrong that way.

That said, yes, this looks like a bug. Specifically, SelectionDAGLegalize::ExpandConstantFP() assumes that f32 is the smallest floating point constant type it’ll need to handle, and that MVT enum ordering reflects that.

  while (SVT != MVT::f32) {                                                      
    SVT = (MVT::SimpleValueType)(SVT.getSimpleVT().SimpleTy - 1); 
    ...
  }

That function, and possibly others, need to be taught how to handle half-floats, it looks like.

-Jim

On Jun 17, 2013, at 6:59 AM, Alessio Giovanni Baroni <[hidden email]> wrote:

Hi,

if I write the following simple program:

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16: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"

define void @foo () {
    %1 = alloca half
    store half 0xH42CC, half* %1   ; 0xH42CC = 3.4
    %2 = load half* %1
    ret void
}

llc goes in SIGABRT. In the reference manual says that it's  correct syntax.

It's a bug?

Thanks.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Failure handling half type

Alessio Giovanni Baroni
I don't.


2013/6/29 Keno Fischer <[hidden email]>
Just ran into this as well. Did you ever open a a bug report about it?


On Tue, Jun 18, 2013 at 3:43 AM, Alessio Giovanni Baroni <[hidden email]> wrote:
Here there is the dump:

SelectionDAG.cpp:81: static bool llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, const llvm::APFloat &): Assertion `VT.isFloatingPoint() && "Can only convert between FP types"' failed.
0  libLLVMSupport.so      0x00007f7405022de5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37
1  libLLVMSupport.so      0x00007f74050232e3
2  libpthread.so.0        0x00007f7404960cb0
3  libc.so.6              0x00007f7403bba425 gsignal + 53
4  libc.so.6              0x00007f7403bbdb8b abort + 379
5  libc.so.6              0x00007f7403bb30ee
6  libc.so.6              0x00007f7403bb3192
7  libLLVMSelectionDAG.so 0x00007f7408266500 llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, llvm::APFloat const&) + 320
8  libLLVMSelectionDAG.so 0x00007f74081df6cf
9  libLLVMSelectionDAG.so 0x00007f74081d12b1
10 libLLVMSelectionDAG.so 0x00007f74081cff57 llvm::SelectionDAG::Legalize() + 375
11 libLLVMSelectionDAG.so 0x00007f74082d6604 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3700
12 libLLVMSelectionDAG.so 0x00007f74082d4f07 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 6455
13 libLLVMSelectionDAG.so 0x00007f74082d2876 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1318
14 libLLVMCodeGen.so      0x00007f74074885dd llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 125
15 libLLVMCore.so         0x00007f740583e2ac llvm::FPPassManager::runOnFunction(llvm::Function&) + 364
16 libLLVMCore.so         0x00007f740583e52b llvm::FPPassManager::runOnModule(llvm::Module&) + 59
17 libLLVMCore.so         0x00007f740583e8d7 llvm::MPPassManager::runOnModule(llvm::Module&) + 519
18 libLLVMCore.so         0x00007f740583ef6b llvm::PassManagerImpl::run(llvm::Module&) + 539
19 libLLVMCore.so         0x00007f740583f0da llvm::PassManager::run(llvm::Module&) + 10
20 llc                    0x000000000040839c
21 libc.so.6              0x00007f7403ba576d __libc_start_main + 237
22 llc                    0x0000000000406d7d
Stack dump:
0.    Program arguments: llc -asm-verbose -filetype=asm -o qwe.S qwe.ll
1.    Running pass 'Function Pass Manager' on module 'qwe.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo'


A small note: this is LLVM 3.3 final linked with libc++ on Ubuntu Linux 12.10.


2013/6/17 Jim Grosbach <[hidden email]>
Make sure you’re running LLVM with assertions enabled. You’ll get more information about what’s going wrong that way.

That said, yes, this looks like a bug. Specifically, SelectionDAGLegalize::ExpandConstantFP() assumes that f32 is the smallest floating point constant type it’ll need to handle, and that MVT enum ordering reflects that.

  while (SVT != MVT::f32) {                                                      
    SVT = (MVT::SimpleValueType)(SVT.getSimpleVT().SimpleTy - 1); 
    ...
  }

That function, and possibly others, need to be taught how to handle half-floats, it looks like.

-Jim

On Jun 17, 2013, at 6:59 AM, Alessio Giovanni Baroni <[hidden email]> wrote:

Hi,

if I write the following simple program:

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16: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"

define void @foo () {
    %1 = alloca half
    store half 0xH42CC, half* %1   ; 0xH42CC = 3.4
    %2 = load half* %1
    ret void
}

llc goes in SIGABRT. In the reference manual says that it's  correct syntax.

It's a bug?

Thanks.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev