[llvm-dev] Instruction selection for 'load' based on static vs. dynamic data

Krzysztof Parzyszek via llvm-dev llvm-dev at lists.llvm.org
Mon May 8 07:11:03 PDT 2017


You can create the differentiation between objects in the data memory 
and in the program memory in LowerGlobalAddress (e.g. you can create 
different ISD opcodes that generate these addresses) and then use those 
to select corresponding instructions.

-Krzysztof

On 5/7/2017 10:39 AM, Dr. ERDI Gergo via llvm-dev wrote:
> Hi,
> 
> I've been looking at the new AVR backend lately, and one issue I've
> found is that all 'load' IR instructions are matched using the 'ld'
> AVR instruction, including 'load's for lookup tables generated from
> switches.
> 
> On the AVR architecture, RAM and the program image are in completely
> separated namespaces. There's a distinct 'lpm' (Load from Program
> Memory) instruction that can load data from .text. So the nice way of
> getting this to work is to select 'lpm' for those switch lookup table
> 'load's, thereby avoiding the memory footprint and the runtime cost of
> copying the tables to RAM at startup. However, we still need to select
> 'ld' for other 'load's.
> 
> To give a concrete example, here's an LLVM IR snippet that should be
> lowered to 'lpm':
> 
>      @switch.table = private unnamed_addr constant [15 x i8] 
> c"\01\01\01\01\01\00\00\00\00\00\00\00\00\00\01"
> 
>      switch.lookup:                                    ; preds = %start
>        %2 = sext i8 %0 to i16
>        %switch.gep = getelementptr inbounds [15 x i8], [15 x i8]* 
> @switch.table, i16 0, i16 %2
>        %switch.load = load i8, i8* %switch.gep, align 1
>        br label %bb8
> 
> and here's one that should be lowered to 'ld':
> 
>      %S = type { i8 }
> 
>      start:
>        %1 = getelementptr inbounds %S, %S* %0, i16 0, i32 0
>        %2 = load i8, i8* %1, align 1
>        ret i8 %2
>      }
> 
> So my question is, what kind of pattern matching can I do in my 'lpm'
> and 'ld' instructions that it would be able to make a distinction
> about these two usecases?
> 
> 
> Thanks,
>          Gergo
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation


More information about the llvm-dev mailing list