page 1 open source | open possibilities may contain u.s. and international export controlled...

Open Source | Open Possibilities MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION

Open Source | Open Possibilities

Building the Linux Kernel and User Space for the Hexagon™ DSP with LLVM

Anshu Dasgupta and Pavel PotoplyakLinux Plumbers ConferenceSeptember 19, 2013Credits: Thomas Brezinski and Anand Kodnani


Qualcomm Innovation Center, Inc.5775 Morehouse DriveSan Diego, CA 92121

U.S.A.

© 2013 Qualcomm Innovation Center, Inc.

Not to be used, copied, reproduced, or modified in whole or in part, nor its contents revealed in any manner to others without the express written permission of Qualcomm Innovation Center, Inc.

Qualcomm is a trademark of QUALCOMM Incorporated, registered in the United States and other countries. All QUALCOMM Incorporated trademarks are used with permission. Other product and brand names may be trademarks or registered trademarks of their respective owners.

This technical data may be subject to U.S. and international export, re-export or transfer (“export”) laws. Diversion contrary to U.S. and international law is strictly prohibited.

Presentation Title80-BAxxx-x Rev. x


Introduction

Who are we? Anshu Dasgupta – manage Qualcomm’s Hexagon™ DSP compiler team Pavel Potoplyak – engineer working with the Hexagon tools team


Introduction

What are we doing?

Bringing up a LLVM compiler for the Hexagon™ DSP GCC is a mature toolset with thousands of hours of testing behind it How do we achieve that level of robustness and maturity?

One solution: Build Linux kernel and user space with LLVM for the Hexagon™ DSP


Introduction

Why are we building the Linux kernel and user space with LLVM?

Compiler testing

• Need extensive testing to deploy commercially

• VLIW code paths and optimizations a challenge for correctness, performance

• Compiler bugs are very difficult to track down in embedded applications

Hexagon codebases transitioning from GCC to LLVM

• Programmers code to compiler behavior not to C standard


Hexagon™ DSP

Hexagon™ DSP: Qualcomm’s multithreaded VLIW DSP

• Part of the Snapdragon platform

C, C++ compiler

• Processor designed to be programmed in C and C++

• LLVM-based compiler (transitioned from GCC compiler)

VLIW architecture provides several opportunities and challenges for the compiler


Compiler CorrectnessPrimary goal of compiler: Generate correct code

• Relax correctness and any performance goal can be met :-)

• We have an elaborate set of internal tests for correctness that runs every night

Compiling Hexagon DSP Linux kernel and user space with LLVM Stress test for compiler correctness

• Several bugs uncovered during Hexagon Linux bringup

Example packet:{ r7 += mpyi(r21, r20)

r8 = add(r8, #16)

r12 = add(r12, #8)

if (cmp.gt(r2, r12.new)) jump:t .LBB0_4

}


Example of Unsupported Feature: Global Register Variables

#ifndef __llvm__

register struct thread_info *__current_thread_info asm(QUOTED_THREADINFO_REG);

#define current_thread_info() __current_thread_info

#else

inline struct thread_info *current_thread_info()

{

struct thread_info *x;

asm ("%0 = " QUOTED_THREADINFO_REG : "=r"(x));

return x;

}

#endif

Several other GCC extensions not implemented in LLVM

http://clang.llvm.org/docs/UsersManual.html#gcc-extensions-not-implemented-yet




Example of Compiler Exploiting C99 Undefined Behavior

char *killer = NULL;

#ifndef __llvm__

*killer = 1;

#else

__asm__ __volatile__(

"r0 = #0\n\t"

"r1 = #1\n\t"

"memb(r0+#0) = r1\n\t"

::: "r0", "r1", "memory");

#endif


Esoteric Difference #1: File Scope Inline ASM

void sleep1()

{

sleep(1);

}

/* notice nop placed between two functions */

asm("nop");

void sleep2()

{

sleep(2);

}


Esoteric Difference #1:GCC code generation with –fno-toplevel-reorder.file "example1.c"

.text

.type sleep1, @function

sleep1:

allocframe(#0)

r0 = #1

call sleep

deallocframe

jumpr r31

.size sleep1, .-sleep1

//APP

nop # NOTICE NOP PLACEMENT

//NO_APP

.p2align 2

.globl sleep2

.type sleep2, @function

sleep2:

allocframe(#0)

...


Esoteric Difference #1: LLVM code generation

.file "example1.c"

nop # NOTICE NOP PLACEMENT

.text

.type sleep1,@function

sleep1:

allocframe(#8)

r0 = #1

call sleep

memw(r29+#4) = r0

dealloc_return

.Ltmp0:

.type sleep1,@function

allocframe(#8)

...


Esoteric Difference #2: Controlling Names in Assembler Code

void f1()

{

f2();

}

extern int f2() asm ("f3");


Esoteric Difference #2: GCC code generation

.file "example2.c"

.text

.p2align 2

.globl f1

.type f1, @function

f1:

// saved LR + FP regs size (bytes) = 8

allocframe(#0)

call f3 # NOTICE CALL TO f3

deallocframe

jumpr r31

.size f1, .-f1


Esoteric Difference #2: LLVM code generation

.file "example2.c"

.text

.globl f1

.falign

.type f1,@function

f1:

allocframe(#8)

call f2 # NOTICE CALL TO f2

memw(r29+#4) = r0

dealloc_return

.Ltmp0:

.size f1, .Ltmp0-f1


Esoteric Difference #3: Preprocessing

$ echo '#include "foo.h"' | \

hexagon-clang -E -dM -MD -MP -MF foo.out -xc - -o out.out -MT 'a b'

$ cat foo.out

a b: <stdin> foo.h

foo.h:

$ echo '#include "foo.h"' | \

hexagon-gcc -E -dM -MD -MP -MF foo.out -xc - -o out.out -MT a b'

$ cat foo.out

a b: foo.h

foo.h:


Conclusion

Our conclusion Built more than 55 user space packages with LLVM for Hexagon DSP Uncovered several latent compiler bugs Buiding and running large codebases through toolset is extremely

beneficial Significantly improves the quality of the compiler shipped to our

customers Would like to automate the build without any source code changes


Open Questions

How do you quantify the quality of the toolset, kernel and user space?• Components change. For instance: new compiler, new optimizations

• What are the different dimensions of measurable quality• Correctness

• Build time

• Code size

• Execution time

• How do we capture, archive, and analyze these metrics on a macro scale?

Which GCC-isms should LLVM support? Which GCC-isms should be eliminated from Linux user space?

page 1 open source | open possibilities may contain u.s. and international export controlled...

Documents

compiler slide

llvm compiler

hexagon dsp slide

compiler testing

hexagon dsp gcc

compiler behavior

c llvmbased compiler

c compiler processor