[llvm-dev] Beginner question: extending pointer to 128 bits segfaults

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 15 17:41:58 PST 2018


While its true that X86 has 128-bit registers for SSE. There are no
instructions for doing 128-bit arithmetic on them. So for example, you
can't add two 128 bit registers and get a 128 bit result. Because of this
i128 isn't considered a legal type by the X86 backend. It doesn't have a
register class assigned to it via a call to addRegisterClass in
X86ISelLowering.cpp.

It's also not possible in the X86 backend today to use an XMM register in
the address calculations for a load or store.

I think in general the pointer type also needs to be listed as a valid
integer type in the data layout string too.

But I'm not sure why you got the particular seg fault you go.

~Craig

On Mon, Jan 15, 2018 at 5:23 PM, Barbora Murinov√° via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all,
>
> I've been trying to extend pointer size of the X86 target to 128 bits. For
> the prortype, I would like nothing more than the pointers being i128 type
> with the same value as before. All I've done was changing the data layout
> string to p:128:128 and when trying to run a basic program such as:
>
> int a = 42;
> int *p = &a;
>
> it segfaults with the following stack trace:
>
> #0 0x00000000013eff7a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
> /afs/inf.ed.ac.uk/user/s14/s1455152/Documents/HP/llvm/
> lib/Support/Unix/Signals.inc:402:0
> #1 0x00000000013ee20e llvm::sys::RunSignalHandlers() /afs/
> inf.ed.ac.uk/user/s14/s1455152/Documents/HP/llvm/
> lib/Support/Signals.cpp:50:0
> #2 0x00000000013ee34a SignalHandler(int) /afs/inf.ed.ac.uk/user/s14/
> s1455152/Documents/HP/llvm/lib/Support/Unix/Signals.inc:242:0
> #3 0x00007fad6b434370 __restore_rt (/lib64/libpthread.so.0+0xf370)
> #4 0x0000000001ba1734 llvm::DAGTypeLegalizer::PromoteIntOp_ATOMIC_STORE(
> llvm::AtomicSDNode*)
> /afs/inf.ed.ac.uk/user/s14/s1455152/Documents/HP/llvm/
> lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:1025:0
> Stack dump:
> 0.      Program arguments: /afs/inf.ed.ac.uk/user/s14/
> s1455152/Documents/HP/build/bin/clang-6.0 -cc1 -triple
> x86_64-unknown-linux-gnu -emit-obj
> -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names
> -main-file-name simple.c -mrelocation-model static -mthread-model posix
> -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
> -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
> -debugger-tuning=gdb -resource-dir /afs/inf.ed.ac.uk/user/s14/
> s1455152/Documents/HP/build/lib/clang/6.0.0 -internal-isystem
> /usr/local/include
> -internal-isystem /afs/inf.ed.ac.uk/user/s14/s1455152/Documents/HP/build/
> lib/clang/6.0.0/include -internal-externc-isystem /include
> -internal-externc-isystem /usr/include -fdebug-compilation-dir /afs/
> inf.ed.ac.uk/user/s14/s1455152/Documents/HP/build -ferror-limit 19
> -fmessage-length
> 159 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o
> /tmp/simple-2837aa.o -x c ../copy/simple.c
> 1.      <eof> parser at end of file
> 2.      Code generation
> 3.      Running pass 'Function Pass Manager' on module '../copy/simple.c'.
> 4.      Running pass 'X86 DAG->DAG Instruction Selection' on function
> '@main'
> clang-6.0: error: unable to execute command: Segmentation fault
> clang-6.0: error: clang frontend command failed due to signal (use -v to
> see invocation)
>
> Now I know almost nothing about LLVM, but I assumed that since X86 target
> has SSE extensions, it wouldn't have a problem with a 128-bit value type in
> general. I would really appreciate any explanations and pointers you can
> give me. Sorry for such a general question.
>
> Best wishes,
> Barbora
>
> --
> ----------------
> Barbora Murinov√°
> The University of Edinburgh
> SK: +421905718390 <+421%20905%20718%20390>
> UK: +447477833795 <+44%207477%20833795>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180115/d026c73a/attachment.html>


More information about the llvm-dev mailing list