Browse Prior Art Database

A framework for simdization of function calls. Disclosure Number: IPCOM000226852D
Publication Date: 2013-Apr-23
Document File: 3 page(s) / 43K

Publishing Venue

The Prior Art Database


Disclosed is a method that allows compilers to more aggressively set codes with function calls to Single Instruction, Multiple Data (SIMD) form. It extends the set of simdizable function calls to user defined functions and the set of simdizable function calls is no longer fixed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 01 of 3

A framework for simdization of function calls.

The ultimate goal of many new improvements in computer hardware and software is to run code faster. Central Processing Unit (CPU) architecture has changed rapidly by providing new features that allow faster code execution. One of these changes is introduction of Single Instruction, Multiple Data (SIMD) Instruction Set Architecture (ISA) and registers. This allows programmers to do one operation on multiple units of data at the same time and provides a fine grain mechanism for parallelism .

Modifying sequential user code by the compiler such that it takes advantage of SIMD ISA and registers on the CPU is called auto-simdization. In order to auto-simdize user code legally, compilers investigate a number of properties of the code; among other things, the computation should be doable in the SIMD form and simdization should not break the dependencies among memory references .

To auto-simdize a piece of code that contains function calls, the compiler has to answer a number of questions:

1. How should simdization and inlining interact? Performing inlining before simdization, may make the code more complicated and harder to simdize . Performing inlining after the simdization, leaves the questions that come next in this list.

2. Is it possible to simdize a code that contains functions calls? How should developers distinguish which function calls are simdizable and which function calls are not simdizable?

3. Does the potentially hidden body of the function introduce any dependencies between memory references that makes simdization illegal?

4. While in the scalar code, the function's input and output are scalar. How should the function be called in the simdized code? Should developers interact with the function using scalar variables and simdize the rest of the code, or change the input and output of the function to vectors rather than scalars?

Given the challenges posed by the above questions, traditionally, simdization frameworks tend to become very conservative upon finding a function call in the code that they want to simdize.

To answer question #1, usually inlining heuristics have no knowledge of simdization and inlining decisions are made completely independent of simdizability of the code . Question #2 is answered by limiting the simdizable function calls to a limited set of functions hard coded in the compiler. To address questions #3 and #4, the function calls are changed to one with vector inputs and outputs. Functions are limited to hardware instrinsics or functions in libraries of which the compiler is aware of having vector versions. In addition, usually, these sets of functions are fixed and cannot be extended.

The invented method allows compilers to more aggressively simdize codes with function calls. It extends the set of simdizable function calls to user defined functions and the set of simdizable function calls is no longer fixed . Inlining is becoming aware of simdization, so...