DOCSLIB.ORG

High-Level Synthesis and Arithmetic Optimizations Yohann Uguen

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

High-level synthesis and arithmetic optimizations Yohann Uguen To cite this version: Yohann Uguen. High-level synthesis and arithmetic optimizations. Mechanics [physics.med-ph]. Uni- versité de Lyon, 2019. English. NNT : 2019LYSEI099. tel-02420901v2 HAL Id: tel-02420901 https://hal.archives-ouvertes.fr/tel-02420901v2 Submitted on 17 Jul 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. N°d'ordre NNT : 2019LYSEI099 THESE` de DOCTORAT DE L'UNIVERSITE´ DE LYON Op´er´eeau sein de : (INSA de Lyon, CITI lab) Ecole Doctorale InfoMaths EDA 512 (Informatique Math´ematique) Sp´ecialit´ede doctorat : Informatique Soutenue publiquement le 13/11/2019, par : Yohann Uguen High-level synthesis and arithmetic optimizations Devant le jury compos´ede : Fr´ed´ericP´etrot Pr´esident Professeur des Universit´es, TIMA, Grenoble, France Philippe Coussy Rapporteur Professeur des Universit´es, UBS, Lorient, France Olivier Sentieys Rapporteur Professeur des Universit´es, Univ. Rennes, Inria, IRISA, Rennes Laure Gonnord Examinatrice Ma^ıtrede conf´erence, Universit´eLyon 1, France Martin Kumm Examinateur Professeur des Universit´es, Universit´ede Fulda, Allemagne Florent de Dinechin Directeur de th`ese Professeur des Universit´es, INSA Lyon, France Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2019LYSEI099/these.pdf © [Y. Uguen], [2019], INSA Lyon, tous droits réservés Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2019LYSEI099/these.pdf © [Y. Uguen], [2019], INSA Lyon, tous droits réservés R´esum´e A` cause de la nature relativement jeune des outils de synth`esede haut-niveau (HLS), de nombreuses optimisations arithm´etiquesn'y sont pas encore impl´ement´ees.Cette th`ese propose des optimisations arithm´etiquesse servant du contexte sp´ecifiquedans lequel les op´erateurs sont instanci´es. Certaines optimisations sont de simples sp´ecialisations d'op´erateurs,respectant la s´emantique du C. D'autres n´ec´essitent de s'´eloignerde cette s´emantique pour am´eliorerle compromis pr´ecision/co^ut/performance. Cette proposition est d´emontr´esur des sommes de produits de nombres flottants. La somme est r´ealis´ee dans un format en virgule-fixe d´efinipar son contexte. Quand trop peu d'informations sont disponibles pour d´efinir ce format en virgule-fixe, une strat´egieest de g´en´ererun accumulateur couvrant l'int´egralit´edu format flottant. Cette th`eseexplore plusieurs impl´ementations d'un tel accumulateur. L'utilisation d'une repr´esentation en compl´ement `adeux permet de r´eduirele chemin critique de la boucle d'accumulation, ainsi que la quantit´ede ressources utilis´ees. Un format alternatif aux nombres flottants, appel´eposit, propose d'utiliser un encodage `apr´ecisionvariable. De plus, ce format est augment´epar un accumulateur exact. Pour ´evaluer pr´ecis´ement le co^utmat´eriel de ce format, cette th`esepr´esente des architectures d'op´erateursposits, impl´ement´esavec le m^emedegr´ed'optimisation que celui de l'´etat de l'art des op´erateursflottants. Une analyse d´etaill´eemontre que le co^utdes op´erateurs posits est malgr´etout bien plus ´elev´eque celui de leurs ´equivalents flottants. Enfin, cette th`esepr´esente une couche de compatibilit´eentre outils de HLS, permettant de viser plusieurs outils avec un seul code. Cette biblioth`equeimpl´emente un type d'entiers de taille variable, avec de plus une s´emantique strictement typ´ee,ainsi qu'un ensemble d'op´erateursad-hoc optimis´es. 1 Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2019LYSEI099/these.pdf © [Y. Uguen], [2019], INSA Lyon, tous droits réservés 2 Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2019LYSEI099/these.pdf © [Y. Uguen], [2019], INSA Lyon, tous droits réservés Abstract High-level synthesis (HLS) tools offer increased productivity regarding FPGA program- ming. However, due to their relatively young nature, they still lack many arithmetic optimizations. This thesis proposes safe arithmetic optimizations that should always be applied. These optimizations are simple operator specializations, following the C semantic. Other require to a lift the semantic embedded in high-level input program languages, which are inherited from software programming, for an improved accuracy/cost/performance ratio. To demonstrate this claim, the sum-of-product of floating-point numbers is used as a case study. The sum is performed on a fixed-point format, which is tailored to the application, according to the context in which the operator is instantiated. In some cases, there is not enough information about the input data to tailor the fixed- point accumulator. The fall-back strategy used in this thesis is to generate an accumulator covering the entire floating-point range. This thesis explores different strategies for implementing such a large accumulator, including new ones. The use of a 2's complement representation instead of a sign+magnitude is demonstrated to save resources and to reduce the accumulation loop delay. Based on a tapered precision scheme and an exact accumulator, the posit number systems claims to be a candidate to replace the IEEE floating-point format. A throughout analysis of posit operators is performed, using the same level of hardware optimization as state-of-the-art floating-point operators. Their cost remains much higher that their floating-point counterparts in terms of resource usage and performance. Finally, this thesis presents a compatibility layer for HLS tools that allows one code to be deployed on multiple tools. This library implements a strongly typed custom size integer type along side a set of optimized custom operators. 3 Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2019LYSEI099/these.pdf © [Y. Uguen], [2019], INSA Lyon, tous droits réservés 4 Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2019LYSEI099/these.pdf © [Y. Uguen], [2019], INSA Lyon, tous droits réservés CONTENTS Contents 1 Introduction 9 2 Context 13 2.1 Representing real numbers . 13 2.1.1 Fixed-point representation . 13 2.1.2 Floating-point representation . 15 2.2 Field Programmable Gate Arrays (FPGAs) . 20 2.2.1 FPGAs architecture . 20 2.2.2 FPGAs programming model . 23 3 Bridging high-level synthesis and application specific arithmetic 29 3.1 Optimization examples that do not change the program semantic . 31 3.1.1 Floating-point corner-case optimization . 31 3.1.2 Integer multiplication by a constant . 33 3.1.3 Integer division by small constants . 33 3.1.4 Floating-point multiplications and divisions by small constants . 36 3.1.5 Evaluation in context . 37 3.2 Optimization examples that change the program semantic . 38 3.2.1 High-level synthesis (HLS) faithful to the floats . 38 3.2.2 Towards HLS faithful to the reals . 39 3.2.3 The arithmetic side: application-specific accumulator support . 40 3.2.4 The compiler side: source-to-source transformation . 43 3.2.5 Evaluation in context . 48 3.3 Discussion . 51 4 Architecture exploration of exact floating-point accumulators 53 4.1 Parameters of an accumulator for exact sums and sums-of-products . 54 4.2 Kulisch-1: Long adder and long shift . 55 4.2.1 Kulisch-1 with the accumulator in sign+magnitude . 55 4.2.2 Kulisch-1 with the accumulator in 2's complement . 56 4.2.3 Kulisch-1 high-radix carry-save architecture . 57 4.3 Segmenting the accumulator into words . 58 4.3.1 Kulisch-2: Segmented accumulator in RAM . 58 4.3.2 Kulisch-3: Sub-adders with delayed carry propagation . 59 4.4 Recovering the accumulator values . 61 4.5 Evaluation of Kulisch accumulators . 63 4.5.1 Cost/frequency/latency trade-off . 64 5 Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2019LYSEI099/these.pdf © [Y. Uguen], [2019], INSA Lyon, tous droits réservés CONTENTS 4.5.2 Comparisons with plain floating-point accumulation . 65 4.6 Discussion . 66 5 Architecture exploration of operators for the posit number system 67 5.1 Posit representation . 68 5.1.1 Decoding posits . 68 5.1.2 Posits bounds and sizes . 69 5.2 Architecture . 70 5.2.1 Posit intermediate format (PIF) . 70 5.2.2 Posit to PIF decoder . 71 5.2.3 PIF to posit encoder . 72 5.2.4 PIF adder/subtracter and multiplier . 73 5.2.5 Quire . 75 5.3 Evaluation . 76 5.3.1 Comparison with state-of-the-art posit implementations . 76 5.3.2 Comparison with floating-point operators . 80 5.3.3 Quire evaluation . 81 5.4 Using posits as a storage format only . 82 5.5 Discussion . 85 6 A type-safe arbitrary precision arithmetic portability layer for HLS tools 87 6.1 Background and motivation . 88 6.1.1 Arbitrary-sized integers for HLS . 88 6.1.2 Type safety . 89 6.1.3 Core arithmetic primitives for floating-point and posits . 90 6.1.4 Fused arithmetic primitives . 90 6.1.5 Support of these primitives in HLS tools . 91 6.2 Type safety for arbitrary-precision integers in HLS . 91 6.2.1 Variable declaration . 91 6.2.2 Variable assignment . 91 6.2.3 Slicing . 92 6.2.4 Concatenation . 92 6.2.5 Others . 92 6.3 Portability to mainstream HLS tools .
Recommended publications
  • Arithmetic Algorithms for Extended Precision Using Floating-Point Expansions Mioara Joldes, Olivier Marty, Jean-Michel Muller, Valentina Popescu

    Arithmetic Algorithms for Extended Precision Using Floating-Point Expansions Mioara Joldes, Olivier Marty, Jean-Michel Muller, Valentina Popescu

    Arithmetic algorithms for extended precision using floating-point expansions Mioara Joldes, Olivier Marty, Jean-Michel Muller, Valentina Popescu To cite this version: Mioara Joldes, Olivier Marty, Jean-Michel Muller, Valentina Popescu. Arithmetic algorithms for extended precision using floating-point expansions. IEEE Transactions on Computers, Institute of Electrical and Electronics Engineers, 2016, 65 (4), pp.1197 - 1210. 10.1109/TC.2015.2441714. hal- 01111551v2 HAL Id: hal-01111551 https://hal.archives-ouvertes.fr/hal-01111551v2 Submitted on 2 Jun 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. IEEE TRANSACTIONS ON COMPUTERS, VOL. , 201X 1 Arithmetic algorithms for extended precision using floating-point expansions Mioara Joldes¸, Olivier Marty, Jean-Michel Muller and Valentina Popescu Abstract—Many numerical problems require a higher computing precision than the one offered by standard floating-point (FP) formats. One common way of extending the precision is to represent numbers in a multiple component format. By using the so- called floating-point expansions, real numbers are represented as the unevaluated sum of standard machine precision FP numbers. This representation offers the simplicity of using directly available, hardware implemented and highly optimized, FP operations.
  • Variable Precision in Modern Floating-Point Computing

    Variable Precision in Modern Floating-Point Computing

    Variable precision in modern floating-point computing David H. Bailey Lawrence Berkeley Natlional Laboratory (retired) University of California, Davis, Department of Computer Science 1 / 33 August 13, 2018 Questions to examine in this talk I How can we ensure accuracy and reproducibility in floating-point computing? I What types of applications require more than 64-bit precision? I What types of applications require less than 32-bit precision? I What software support is required for variable precision? I How can one move efficiently between precision levels at the user level? 2 / 33 Commonly used formats for floating-point computing Formal Number of bits name Nickname Sign Exponent Mantissa Hidden Digits IEEE 16-bit “IEEE half” 1 5 10 1 3 (none) “ARM half” 1 5 10 1 3 (none) “bfloat16” 1 8 7 1 2 IEEE 32-bit “IEEE single” 1 7 24 1 7 IEEE 64-bit “IEEE double” 1 11 52 1 15 IEEE 80-bit “IEEE extended” 1 15 64 0 19 IEEE 128-bit “IEEE quad” 1 15 112 1 34 (none) “double double” 1 11 104 2 31 (none) “quad double” 1 11 208 4 62 (none) “multiple” 1 varies varies varies varies 3 / 33 Numerical reproducibility in scientific computing A December 2012 workshop on reproducibility in scientific computing, held at Brown University, USA, noted that Science is built upon the foundations of theory and experiment validated and improved through open, transparent communication. ... Numerical round-off error and numerical differences are greatly magnified as computational simulations are scaled up to run on highly parallel systems.
  • Floating Points

    Floating Points

    Jin-Soo Kim ([email protected]) Systems Software & Architecture Lab. Seoul National University Floating Points Fall 2018 ▪ How to represent fractional values with finite number of bits? • 0.1 • 0.612 • 3.14159265358979323846264338327950288... ▪ Wide ranges of numbers • 1 Light-Year = 9,460,730,472,580.8 km • The radius of a hydrogen atom: 0.000000000025 m 4190.308: Computer Architecture | Fall 2018 | Jin-Soo Kim ([email protected]) 2 ▪ Representation • Bits to right of “binary point” represent fractional powers of 2 • Represents rational number: 2i i i–1 k 2 bk 2 k=− j 4 • • • 2 1 bi bi–1 • • • b2 b1 b0 . b–1 b–2 b–3 • • • b–j 1/2 1/4 • • • 1/8 2–j 4190.308: Computer Architecture | Fall 2018 | Jin-Soo Kim ([email protected]) 3 ▪ Examples: Value Representation 5-3/4 101.112 2-7/8 10.1112 63/64 0.1111112 ▪ Observations • Divide by 2 by shifting right • Multiply by 2 by shifting left • Numbers of form 0.111111..2 just below 1.0 – 1/2 + 1/4 + 1/8 + … + 1/2i + … → 1.0 – Use notation 1.0 – 4190.308: Computer Architecture | Fall 2018 | Jin-Soo Kim ([email protected]) 4 ▪ Representable numbers • Can only exactly represent numbers of the form x / 2k • Other numbers have repeating bit representations Value Representation 1/3 0.0101010101[01]…2 1/5 0.001100110011[0011]…2 1/10 0.0001100110011[0011]…2 4190.308: Computer Architecture | Fall 2018 | Jin-Soo Kim ([email protected]) 5 Fixed Points ▪ p.q Fixed-point representation • Use the rightmost q bits of an integer as representing a fraction • Example: 17.14 fixed-point representation
  • Integers in C: an Open Invitation to Security Attacks?

    Integers in C: an Open Invitation to Security Attacks?

    Integers In C: An Open Invitation To Security Attacks? Zack Coker Samir Hasan Jeffrey Overbey [email protected] [email protected] [email protected] Munawar Hafiz Christian Kästnery [email protected] Auburn University yCarnegie Mellon University Auburn, AL, USA Pittsburgh, PA, USA ABSTRACT integer type is assigned to a location with a smaller type, We performed an empirical study to explore how closely e.g., assigning an int value to a short variable. well-known, open source C programs follow the safe C stan- Secure coding standards, such as MISRA's Guidelines for dards for integer behavior, with the goal of understanding the use of the C language in critical systems [37] and CERT's how difficult it is to migrate legacy code to these stricter Secure Coding in C and C++ [44], identify these issues that standards. We performed an automated analysis on fifty-two are otherwise allowed (and sometimes partially defined) in releases of seven C programs (6 million lines of preprocessed the C standard and impose restrictions on the use of inte- C code), as well as releases of Busybox and Linux (nearly gers. This is because most of the integer issues are benign. one billion lines of partially-preprocessed C code). We found But, there are two cases where the issues may cause serious that integer issues, that are allowed by the C standard but problems. One is in safety-critical sections, where untrapped not by the safer C standards, are ubiquitous|one out of four integer issues can lead to unexpected runtime behavior. An- integers were inconsistently declared, and one out of eight other is in security-critical sections, where integer issues can integers were inconsistently used.
  • Hacking in C 2020 the C Programming Language Thom Wiggers

    Hacking in C 2020 the C Programming Language Thom Wiggers

    Hacking in C 2020 The C programming language Thom Wiggers 1 Table of Contents Introduction Undefined behaviour Abstracting away from bytes in memory Integer representations 2 Table of Contents Introduction Undefined behaviour Abstracting away from bytes in memory Integer representations 3 – Another predecessor is B. • Not one of the first programming languages: ALGOL for example is older. • Closely tied to the development of the Unix operating system • Unix and Linux are mostly written in C • Compilers are widely available for many, many, many platforms • Still in development: latest release of standard is C18. Popular versions are C99 and C11. • Many compilers implement extensions, leading to versions such as gnu18, gnu11. • Default version in GCC gnu11 The C programming language • Invented by Dennis Ritchie in 1972–1973 4 – Another predecessor is B. • Closely tied to the development of the Unix operating system • Unix and Linux are mostly written in C • Compilers are widely available for many, many, many platforms • Still in development: latest release of standard is C18. Popular versions are C99 and C11. • Many compilers implement extensions, leading to versions such as gnu18, gnu11. • Default version in GCC gnu11 The C programming language • Invented by Dennis Ritchie in 1972–1973 • Not one of the first programming languages: ALGOL for example is older. 4 • Closely tied to the development of the Unix operating system • Unix and Linux are mostly written in C • Compilers are widely available for many, many, many platforms • Still in development: latest release of standard is C18. Popular versions are C99 and C11. • Many compilers implement extensions, leading to versions such as gnu18, gnu11.
  • Floating Point Formats

    Floating Point Formats

    Telemetry Standard RCC Document 106-07, Appendix O, September 2007 APPENDIX O New FLOATING POINT FORMATS Paragraph Title Page 1.0 Introduction..................................................................................................... O-1 2.0 IEEE 32 Bit Single Precision Floating Point.................................................. O-1 3.0 IEEE 64 Bit Double Precision Floating Point ................................................ O-2 4.0 MIL STD 1750A 32 Bit Single Precision Floating Point............................... O-2 5.0 MIL STD 1750A 48 Bit Double Precision Floating Point ............................. O-2 6.0 DEC 32 Bit Single Precision Floating Point................................................... O-3 7.0 DEC 64 Bit Double Precision Floating Point ................................................. O-3 8.0 IBM 32 Bit Single Precision Floating Point ................................................... O-3 9.0 IBM 64 Bit Double Precision Floating Point.................................................. O-4 10.0 TI (Texas Instruments) 32 Bit Single Precision Floating Point...................... O-4 11.0 TI (Texas Instruments) 40 Bit Extended Precision Floating Point................. O-4 LIST OF TABLES Table O-1. Floating Point Formats.................................................................................... O-1 Telemetry Standard RCC Document 106-07, Appendix O, September 2007 This page intentionally left blank. ii Telemetry Standard RCC Document 106-07, Appendix O, September 2007 APPENDIX O FLOATING POINT
  • Understanding Integer Overflow in C/C++

    Understanding Integer Overflow in C/C++

    Appeared in Proceedings of the 34th International Conference on Software Engineering (ICSE), Zurich, Switzerland, June 2012. Understanding Integer Overflow in C/C++ Will Dietz,∗ Peng Li,y John Regehr,y and Vikram Adve∗ ∗Department of Computer Science University of Illinois at Urbana-Champaign fwdietz2,[email protected] ySchool of Computing University of Utah fpeterlee,[email protected] Abstract—Integer overflow bugs in C and C++ programs Detecting integer overflows is relatively straightforward are difficult to track down and may lead to fatal errors or by using a modified compiler to insert runtime checks. exploitable vulnerabilities. Although a number of tools for However, reliable detection of overflow errors is surprisingly finding these bugs exist, the situation is complicated because not all overflows are bugs. Better tools need to be constructed— difficult because overflow behaviors are not always bugs. but a thorough understanding of the issues behind these errors The low-level nature of C and C++ means that bit- and does not yet exist. We developed IOC, a dynamic checking tool byte-level manipulation of objects is commonplace; the line for integer overflows, and used it to conduct the first detailed between mathematical and bit-level operations can often be empirical study of the prevalence and patterns of occurrence quite blurry. Wraparound behavior using unsigned integers of integer overflows in C and C++ code. Our results show that intentional uses of wraparound behaviors are more common is legal and well-defined, and there are code idioms that than is widely believed; for example, there are over 200 deliberately use it.
  • 5. Data Types

    5. Data Types

    IEEE FOR THE FUNCTIONAL VERIFICATION LANGUAGE e Std 1647-2011 5. Data types The e language has a number of predefined data types, including the integer and Boolean scalar types common to most programming languages. In addition, new scalar data types (enumerated types) that are appropriate for programming, modeling hardware, and interfacing with hardware simulators can be created. The e language also provides a powerful mechanism for defining OO hierarchical data structures (structs) and ordered collections of elements of the same type (lists). The following subclauses provide a basic explanation of e data types. 5.1 e data types Most e expressions have an explicit data type, as follows: — Scalar types — Scalar subtypes — Enumerated scalar types — Casting of enumerated types in comparisons — Struct types — Struct subtypes — Referencing fields in when constructs — List types — The set type — The string type — The real type — The external_pointer type — The “untyped” pseudo type Certain expressions, such as HDL objects, have no explicit data type. See 5.2 for information on how these expressions are handled. 5.1.1 Scalar types Scalar types in e are one of the following: numeric, Boolean, or enumerated. Table 17 shows the predefined numeric and Boolean types. Both signed and unsigned integers can be of any size and, thus, of any range. See 5.1.2 for information on how to specify the size and range of a scalar field or variable explicitly. See also Clause 4. 5.1.2 Scalar subtypes A scalar subtype can be named and created by using a scalar modifier to specify the range or bit width of a scalar type.
  • Extended Precision Floating Point Arithmetic

    Extended Precision Floating Point Arithmetic

    Extended Precision Floating Point Numbers for Ill-Conditioned Problems Daniel Davis, Advisor: Dr. Scott Sarra Department of Mathematics, Marshall University Floating Point Number Systems Precision Extended Precision Patriot Missile Failure Floating point representation is based on scientific An increasing number of problems exist for which Patriot missile defense modules have been used by • The precision, p, of a floating point number notation, where a nonzero real decimal number, x, IEEE double is insufficient. These include modeling the U.S. Army since the mid-1960s. On February 21, system is the number of bits in the significand. is expressed as x = ±S × 10E, where 1 ≤ S < 10. of dynamical systems such as our solar system or the 1991, a Patriot protecting an Army barracks in Dha- This means that any normalized floating point The values of S and E are known as the significand • climate, and numerical cryptography. Several arbi- ran, Afghanistan failed to intercept a SCUD missile, number with precision p can be written as: and exponent, respectively. When discussing float- trary precision libraries have been developed, but leading to the death of 28 Americans. This failure E ing points, we are interested in the computer repre- x = ±(1.b1b2...bp−2bp−1)2 × 2 are too slow to be practical for many complex ap- was caused by floating point rounding error. The sentation of numbers, so we must consider base 2, or • The smallest x such that x > 1 is then: plications. David Bailey’s QD library may be used system measured time in tenths of seconds, using binary, rather than base 10.
  • A Library for Interval Arithmetic Was Developed

    A Library for Interval Arithmetic Was Developed

    1 Verified Real Number Calculations: A Library for Interval Arithmetic Marc Daumas, David Lester, and César Muñoz Abstract— Real number calculations on elementary functions about a page long and requires the use of several trigonometric are remarkably difficult to handle in mechanical proofs. In this properties. paper, we show how these calculations can be performed within In many cases the formal checking of numerical calculations a theorem prover or proof assistant in a convenient and highly automated as well as interactive way. First, we formally establish is so cumbersome that the effort seems futile; it is then upper and lower bounds for elementary functions. Then, based tempting to perform the calculations out of the system, and on these bounds, we develop a rational interval arithmetic where introduce the results as axioms.1 However, chances are that real number calculations take place in an algebraic setting. In the external calculations will be performed using floating-point order to reduce the dependency effect of interval arithmetic, arithmetic. Without formal checking of the results, we will we integrate two techniques: interval splitting and taylor series expansions. This pragmatic approach has been developed, and never be sure of the correctness of the calculations. formally verified, in a theorem prover. The formal development In this paper we present a set of interactive tools to automat- also includes a set of customizable strategies to automate proofs ically prove numerical properties, such as Formula (1), within involving explicit calculations over real numbers. Our ultimate a proof assistant. The point of departure is a collection of lower goal is to provide guaranteed proofs of numerical properties with minimal human theorem-prover interaction.
  • Signedness-Agnostic Program Analysis: Precise Integer Bounds for Low-Level Code

    Signedness-Agnostic Program Analysis: Precise Integer Bounds for Low-Level Code

    Signedness-Agnostic Program Analysis: Precise Integer Bounds for Low-Level Code Jorge A. Navas, Peter Schachte, Harald Søndergaard, and Peter J. Stuckey Department of Computing and Information Systems, The University of Melbourne, Victoria 3010, Australia Abstract. Many compilers target common back-ends, thereby avoid- ing the need to implement the same analyses for many different source languages. This has led to interest in static analysis of LLVM code. In LLVM (and similar languages) most signedness information associated with variables has been compiled away. Current analyses of LLVM code tend to assume that either all values are signed or all are unsigned (except where the code specifies the signedness). We show how program analysis can simultaneously consider each bit-string to be both signed and un- signed, thus improving precision, and we implement the idea for the spe- cific case of integer bounds analysis. Experimental evaluation shows that this provides higher precision at little extra cost. Our approach turns out to be beneficial even when all signedness information is available, such as when analysing C or Java code. 1 Introduction The “Low Level Virtual Machine” LLVM is rapidly gaining popularity as a target for compilers for a range of programming languages. As a result, the literature on static analysis of LLVM code is growing (for example, see [2, 7, 9, 11, 12]). LLVM IR (Intermediate Representation) carefully specifies the bit- width of all integer values, but in most cases does not specify whether values are signed or unsigned. This is because, for most operations, two’s complement arithmetic (treating the inputs as signed numbers) produces the same bit-vectors as unsigned arithmetic.
  • A Variable Precision Hardware Acceleration for Scientific Computing Andrea Bocco

    A Variable Precision Hardware Acceleration for Scientific Computing Andrea Bocco

    A variable precision hardware acceleration for scientific computing Andrea Bocco To cite this version: Andrea Bocco. A variable precision hardware acceleration for scientific computing. Discrete Mathe- matics [cs.DM]. Université de Lyon, 2020. English. NNT : 2020LYSEI065. tel-03102749 HAL Id: tel-03102749 https://tel.archives-ouvertes.fr/tel-03102749 Submitted on 7 Jan 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. N°d’ordre NNT : 2020LYSEI065 THÈSE de DOCTORAT DE L’UNIVERSITÉ DE LYON Opérée au sein de : CEA Grenoble Ecole Doctorale InfoMaths EDA N17° 512 (Informatique Mathématique) Spécialité de doctorat :Informatique Soutenue publiquement le 29/07/2020, par : Andrea Bocco A variable precision hardware acceleration for scientific computing Devant le jury composé de : Frédéric Pétrot Président et Rapporteur Professeur des Universités, TIMA, Grenoble, France Marc Dumas Rapporteur Professeur des Universités, École Normale Supérieure de Lyon, France Nathalie Revol Examinatrice Docteure, École Normale Supérieure de Lyon, France Fabrizio Ferrandi Examinateur Professeur associé, Politecnico di Milano, Italie Florent de Dinechin Directeur de thèse Professeur des Universités, INSA Lyon, France Yves Durand Co-directeur de thèse Docteur, CEA Grenoble, France Cette thèse est accessible à l'adresse : http://theses.insa-lyon.fr/publication/2020LYSEI065/these.pdf © [A.