[PATCH] strlen -> strnlen optimization

This addition converts strlen() calls to strnlen() when the result is
compared to a constant. For example, the following:

strlen(s) < 5


strnlen(s, 5) < 5

That way, we don't have to walk through the entire string. There is the
added overhead of maintaining a counter when using strnlen(), but I
thought I'd start with the general case. It may make sense to only use
this optimization with small constants. On the other hand, the impact of
the counter may be negligible in many or most cases due to
hardware-level optimizations.

I often notice the idiom of comparing a packet or buffer against a
minimum length as a sanity check. I was surprised to see that this isn't
optimized, so I thought I'd give it a try.

nlewycky on IRC seemed to think it was a good idea. I'm interested to
hear what others think.

I have little C++ experience, so there are likely improvements to be
made to my patch. I tried to adhere to the style and conventions of the
surrounding code.

This reintroduces emitStrNLen(), which was removed a couple months ago
in r253514. The only change is a getParent()->getParent() -->
getModule() conversion, which was done in emitStrLen() after
(Continue reading)

Jack Howarth via llvm-dev | 6 Feb 19:55 2016

D16945: LLVM overhaul to avoid linking LLVM component libraries with libLLVM

      I have posted a complete patch for solving the linkage issues
with LLVM_LINK_LLVM_DYLIB on Phabricator at
http://reviews.llvm.org/D16945.  The bulk of the fix the simple
changes of...

Index: cmake/modules/AddLLVM.cmake
--- cmake/modules/AddLLVM.cmake (revision 259743)
+++ cmake/modules/AddLLVM.cmake (working copy)
 <at>  <at>  -475,13 +475,15  <at>  <at> 
   # property has been set to an empty value.
   get_property(lib_deps GLOBAL PROPERTY LLVMBUILD_LIB_DEPS_${name})

-    set(llvm_libs LLVM)
-  else()
-    llvm_map_components_to_libnames(llvm_libs
-      )
+      set(llvm_libs LLVM)
+    else()
+      llvm_map_components_to_libnames(llvm_libs
+        )
(Continue reading)

Dependency relation between SUnits

I am trying to modify LLVM scheduler and I have a question on SDep. I would be grateful if anyone could answer it:
1. Does the Pred--> Succ relation between Scheduling Units represent the fact that the execution of Succ is dependent to execution of Pred? for example:
I1: Add a,b,c 
I2: Mul d,a,5
I2 needs the result of I1. Does this represented as I1(Pred)-->I2(Succ)? I am confused since the direction in the DAG graph is the opposite of the dependency graph.
If so, for two SUnits: SU and N, can checking SU->isSUcc(N) reveals if N is in anyway dependent to SU?

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

Reducing DWARF emitter memory consumption

Hi all,

We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and
we've found that one of the top consumers of memory is the DWARF emitter in
lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and
I have a few ideas in mind for how to reduce its memory consumption. One
idea I've had is to restructure the emitter so that (for the most part) it
directly produces the bytes and relocations that need to go into the DWARF
sections without going through other data structures such as DIE and DIEValue.

I understand that the DWARF emitter needs to accommodate incomplete entities
that may be completed elsewhere during tree construction (e.g. abstract origins
for inlined functions, special members for types), so here's a quick high-level
sketch of the data structures that I believe could support this design:

struct DIEBlock {
  SmallVector<char, 1> Data;
  std::vector<InternalReloc> IntRelocs;
  std::vector<ExternalReloc> ExtRelocs;
  DIEBlock *Next;

// This would be used to represent things like DW_AT_type references to types
struct InternalReloc {
  size_t Offset; // offset within DIEBlock::Data
  DIEBlock *Target; // the offset within Target is at Data[Offset...Offset+Size]

// This would be used to represent things like pointers to .debug_loc/.debug_str or to functions/globals
struct ExternalReloc {
  size_t Offset; // offset within DIEBlock::Data
  MCSymbol *Target; // the offset within Target is at Data[Offset...Offset+Size]

struct DwarfBuilder {
  DIEBlock *First;
  DIEBlock *Cur;
  DenseMap<DISubprogram *, DIEBlock *> Subprograms;
  DenseMap<DIType *, DIEBlock *> Types;
  DwarfBuilder() : First(new DIEBlock), Cur(First) {}
  // builder implementation goes here...

Normally, the DwarfBuilder will just emit bytes to Cur->Data (with possibly
internal or external relocations to IntRelocs/ExtRelocs), but if it ever
needs to create a "gap" for an incomplete data structure (e.g. at the end of a
subprogram or a struct type), it will create a new DIEBlock New, store it to
Cur->Next, store Cur in a DenseMap associated with the subprogram/type/etc
and store New to Cur. To fill a gap later, the DwarfBuilder can pull the
DIEBlock out of the DenseMap and start appending there. Once the IR is fully
visited, the debug info writer will walk the linked list starting at First,
calculate a byte offset for each DIEBlock, apply any internal relocations
and write Data using the AsmPrinter (e.g. using EmitBytes, or maybe some
other new interface that also supports relocations and avoids copying).

Does that sound reasonable? Is there anything I haven't accounted for?



[1] https://code.google.com/p/chromium/issues/detail?id=583551#c15
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

StringSwitch class


I have a question about the llvm StringSwitch class. Why is this more efficient than comparing the hashes of the strings or just using a bunch of if statements.

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

Why do we have a git tag called "release_35 <at> 215010"?

I.e., I see this when I run `git fetch`:
$ git fetch -v llvm.org
From http://llvm.org/git/llvm
 = [up to date]      master     -> llvm.org/master
 = [up to date]      release_1  -> llvm.org/release_1
 = [up to date]      release_16 -> llvm.org/release_16
 = [up to date]      release_20 -> llvm.org/release_20
 = [up to date]      release_21 -> llvm.org/release_21
 = [up to date]      release_22 -> llvm.org/release_22
 = [up to date]      release_23 -> llvm.org/release_23
 = [up to date]      release_24 -> llvm.org/release_24
 = [up to date]      release_25 -> llvm.org/release_25
 = [up to date]      release_26 -> llvm.org/release_26
 = [up to date]      release_27 -> llvm.org/release_27
 = [up to date]      release_28 -> llvm.org/release_28
 = [up to date]      release_29 -> llvm.org/release_29
 = [up to date]      release_30 -> llvm.org/release_30
 = [up to date]      release_31 -> llvm.org/release_31
 = [up to date]      release_32 -> llvm.org/release_32
 = [up to date]      release_33 -> llvm.org/release_33
 = [up to date]      release_34 -> llvm.org/release_34
 = [up to date]      release_35 -> llvm.org/release_35
 = [up to date]      release_35 <at> 215010 -> llvm.org/release_35 <at> 215010
 = [up to date]      release_36 -> llvm.org/release_36
 = [up to date]      release_37 -> llvm.org/release_37
 = [up to date]      release_38 -> llvm.org/release_38
 = [up to date]      stable     -> llvm.org/stable
 = [up to date]      testing    -> llvm.org/testing
The release_35 <at> 215010 looks bogus.  Why is it there?  If there's no good reason, who has permission to remove it?
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

Unable to evaluate offset when using aliases

We have encountered a problem when using multiple aliases in IR and would like feedback as to whether this use is expected to work properly.

The following IR is causing a failure in llc when lowering to an object file:

; RUN: llc double-alias.ll -filetype=obj -o double-alias.o 
<at> bar = global i32 0
<at> foo2 = alias i32, i32* <at> bar
<at> foo3 = alias i32, i32* <at> foo2
<at> baz = global i32* <at> foo3

Is redirection through multiple aliases supposed to work? If <at> baz is modified to reference <at> foo2 instead of <at> foo3, the IR lowers to an object file successfully.

Without asserts enabled, the following error is seen:
LLVM ERROR: unable to evaluate offset to undefined symbol '_foo2'

With asserts enabled, the following assert is seen:
Assertion failed: ((SymbolContents == SymContentsUnset || SymbolContents == SymContentsOffset) && "Cannot get offset for a common/variable symbol"), function getOffset, file /llvm-3.8-rc1/src/include/llvm/MC/MCSymbol.h, line 317.
0  llc                      0x00000001111c2a5e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1  llc                      0x00000001111c2e99 PrintStackTraceSignalHandler(void*) + 25
2  llc                      0x00000001111bf729 llvm::sys::RunSignalHandlers() + 425
3  llc                      0x00000001111c31e2 SignalHandler(int) + 354
4  libsystem_platform.dylib 0x00007fff885c2eaa _sigtramp + 26
5  llc                      0x0000000111e06635 ErrorCategory + 87253
6  llc                      0x00000001111c2ebb raise + 27
7  llc                      0x00000001111c2f62 abort + 18
8  llc                      0x00000001111c2f4e __assert_rtn + 126
9  llc                      0x0000000110bb988e llvm::MCSymbol::getOffset() const + 126
10 llc                      0x0000000110bbc25d getLabelOffset(llvm::MCAsmLayout const&, llvm::MCSymbol const&, bool, unsigned long long&) + 221
11 llc                      0x0000000110bba362 getSymbolOffsetImpl(llvm::MCAsmLayout const&, llvm::MCSymbol const&, bool, unsigned long long&) + 322
12 llc                      0x0000000110bba456 llvm::MCAsmLayout::getSymbolOffset(llvm::MCSymbol const&) const + 38
13 llc                      0x0000000110b82f21 llvm::MCAssembler::evaluateFixup(llvm::MCAsmLayout const&, llvm::MCFixup const&, llvm::MCFragment const*, llvm::MCValue&, unsigned long long&) const + 625
14 llc                      0x0000000110b85036 llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&, llvm::MCFixup const&) + 182
15 llc                      0x0000000110b85a7f llvm::MCAssembler::layout(llvm::MCAsmLayout&) + 2223
16 llc                      0x0000000110b85f33 llvm::MCAssembler::Finish() + 83
17 llc                      0x0000000110bd07ff llvm::MCObjectStreamer::FinishImpl() + 191
18 llc                      0x0000000110bc2017 (anonymous namespace)::MCMachOStreamer::FinishImpl() + 807
19 llc                      0x0000000110bdba35 llvm::MCStreamer::Finish() + 149
20 llc                      0x0000000110296a21 llvm::AsmPrinter::doFinalization(llvm::Module&) + 5425
21 llc                      0x0000000110a4e5d4 llvm::FPPassManager::doFinalization(llvm::Module&) + 84
22 llc                      0x0000000110a4f7f3 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 3603
23 llc                      0x0000000110a4e766 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 342
24 llc                      0x0000000110a4fd81 llvm::legacy::PassManager::run(llvm::Module&) + 33
25 llc                      0x000000010eece223 compileModule(char**, llvm::LLVMContext&) + 19363
26 llc                      0x000000010eec9621 main + 225
27 libdyld.dylib            0x00007fff85f6a5ad start + 1
28 libdyld.dylib            0x0000000000000005 start + 2047433305
Stack dump:
0. Program arguments: /llvm-3.8-rc1/build/bin/llc double-alias.ll -filetype=obj -o double-alias.o 
Illegal instruction: 4

Thanks for the help,

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org
Mario Guerra via llvm-dev | 5 Feb 20:50 2016

Job opportunity at Qualcomm in Austin

Hi folks,


I’m looking for a developer to join my team in Austin to help develop linker back ends for ARM and AArch64. Given that this is the LLVM dev list, I want to be clear that the work involves close collaboration with our internal LLVM teams so LLVM experience is a definite plus,  but it does not involve direct development on LLVM.


I’m ideally looking for someone with direct relevant experience, but I would consider someone with a solid background in C/C++ development and a willingness to learn about linkers. The job description is included below, if you or someone you know might be interested, please send your resume to me directly at mariog <at> quicinc.com.







Job Id


Job Title

Software Development Tools Engineer - ARM and Hexagon

Post Date



Qualcomm Innovation Center 

Job Area

Engineering - Software 


Texas - Austin 

Job Overview

We are looking for the right person to join our software tools development team for Qualcomm’s next-generation processors. Our focus is ongoing development of a high performance tool chain used to build the code that drives Qualcomm’s various modem and applications processor technologies. The right candidate will work on an optimizing linker for multiple targets, with a focus on developing a linker back end for ARM 32- and 64-bit targets. Responsibilities:

·  Work as part of a small team to design, develop, and deliver new features on a proprietary linker used for Qualcomms embedded projects

·  Fix bugs in existing code as needed

·  Coordinate with internal remote ARM LLVM compiler team to:

-          Establish and maintain an ARM test framework in Austin

-          Assist with internal customer issue triage and resolution

-          Deliver features in timeframe necessary to meet release commitments

·  Communicate with internal customers to understand needs and gather requirements.

Minimum Qualifications

5+ years of experience in the following areas are required:

·  Software development experience programming in C/C++, Python

·  Experience with ARM/AArch64 ISA, preferably direct experience with software tools development

Preferred Qualifications

Preferred skills:

·  Knowledge of embedded systems

·  Ability to work independently as well as within a team

·  Experience with modern software development practices and methodologies

·  Experience with building Android

·  Experience with ARM on-target debug

·  Solid understanding of the ELF file format

·  Solid understanding of linkers and linker-related concepts: oSymbol resolution oRelocations/Fixups oDynamic loading/linking oString merging oGarbage collection oLinker scripts / scatter load files Preference given to candidates with experience working with LLVM and related tools, as well as experience developing software for use on both Windows and Linux.

Education Requirements

Bachelors in Computer Science or Electrical Engineering required
Masters in Computer Science or Electrical Engineering preferred


LLVM, linker, binutils, software developer


LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

[AVX512] KNL 1-byte mask spills/reloads are too wide

Hey guys,

I'm working off an older post LLVM 3.7 snapshot and noticed that KNL
1-byte mask spills+reloads are spilling too wide. The spiller reserves
1-byte for the stack slot, but the move instruction is moving 2-bytes
of data around. This obviously clobbers neighboring stack slots.

kmovw %k1, 767(%rsp)         # [scrubbed]:[scrubbed]
                                               # 1-byte Folded Spill

We only have the KMOVW instruction on KNL to load/store mask
registers, which is why we're moving 2-bytes of data. Seems like the
spilling code should be updated to compensate for the extra byte.

Is this a known problem in 3.7? Has a fix been submitted already?

Thanks guys,
LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

Urgently looking for Compiler / Toolchain Developers in Europe for world leading semiconductor company



I am working with a leading semiconductor company to help them recruit for several Compiler / Toolchain roles in their team in Austria.


The roles are very urgent and although one engineer was offered a position in the team he was counter offered by his current employer. He has told me that a good idea would be to contact the LLVM Development mailing list to ask about posting these positions out to all the members.


Is this something that could be possible and would you be able to assist me with this – I can provide the job specs and info of the company if needed.


Thanks for your time.






Chris Canneaux

Principal Consultant


T. +44 (0)1273 957 888   Direct Line. + 443303352350    M. +44 (0)7912 506 673            

E. ccanneaux <at> eu-recruit.com    W. www.eu-recruit.com

Linkedin. http://uk.linkedin.com/in/chriscanneaux


Referral Scheme – Keen to help someone you know?  If you do recommend them and they find their dream job you can also earn some £’s or €’s!




39 Upper Gardner Street, Brighton, BN1 4AN, UK.

Please consider the environment before printing this e-mail


This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.


European Recruitment Ltd - Company Registered in England, No. 05924374.


LLVM Developers mailing list
llvm-dev <at> lists.llvm.org

replace uses of loadInst with a value


I need to replace all uses of load instructions with the value of its operand. Here is an example:

%16 = load i32, i32* %x

%add = add i32 4, %16

In this case, i would like to have the result as:

%add = add i32 4, %x

and then delete the load instruction. I have tried replaceAllUsesWithValue but i get a type problem.

"llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `New->getType() == getType() && "replaceAllUses of value with new value of different type!"' failed."

LLVM Developers mailing list
llvm-dev <at> lists.llvm.org