similar to: grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?

> On Jul 25, 2016, at 20:53, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > Isn’t something a linker could/should do? We have a problem where some globals are lowered to an immediate address in the DAG. It would be nice if we had some fixed order for the globals before then. Right now the total allocated size at the end depends on the use order, block by

On 07/26/2016 12:02 PM, Matt Arsenault wrote: > We have a problem where some globals are lowered to an immediate address in the DAG. My apologies, but I don`t think I really understood that statement. Could anybody please expand/explain? Regards, Abe

>> My question this time is this: is re-ordering globals at the LLVM level both possible [...] On 07/25/2016 10:53 PM, Mehdi Amini wrote: > Isn’t something a linker could/should do? AFAIK & TTBOMK, a compiler should do it [if allowed by the language] and a linker should not mess it up. I don`t know that a linker is allowed to make assumptions about code not traversing labels in

On 09/09/2016 04:31 PM, Stephen Canon wrote: > Gating this on -Owhatever is dangerous, . We should simply default to the pragma “on” state universally. Why so? [honestly asking, not arguing] My guess: b/c we don`t want programs to give different results when compiled at different "-O<...>" settings with the exception of "-Ofast". At any rate, the above change is

----- Original Message ----- > From: "Matthias Braun via cfe-dev" <cfe-dev at lists.llvm.org> > To: "Abe Skolnik" <a.skolnik at samsung.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org> > Sent: Thursday, September 29, 2016 6:20:09 PM > Subject: Re: [cfe-dev] [llvm-dev] improving

Dear all, I would like some help, please, with implementing Hal`s excellent suggestion, which I have reworded as below. Hal has confirmed a previous version of my rewording as a correct interpretation. [I made minor changes since then, e.g. for grammar.] [Abe wrote:] >> I think you [Hal] are suggesting something like this: >> 1) compile the program with FP fusion off,

On Wed, Oct 12, 2016 at 10:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Sebastian Pop" <sebpop.llvm at gmail.com> > Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias Braun" > <matze at braunis.de>, "Clang Dev" <cfe-dev

Dear all, The below has been tested quite thoroughly by now, including performance-testing by the way of using a modified compiler that triggers the below while compiling at least an old part of LLVM ["Function.cpp"] and sorting a symbol table with >7000 global variables. Unfortunately, the optimization I have been working on for which I _thought_ I needed the ability to sort a

----- Original Message ----- > From: "Sebastian Pop" <sebpop.llvm at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Sebastian Paul Pop" <s.pop at samsung.com>, "Abe Skolnik" > <a.skolnik at samsung.com>, "cfe-dev" <cfe-dev at

On 08/04/2016 01:33 PM, David Majnemer wrote: > You should never be copying or moving around Values. Why not? Is that because of this thing you also wrote in the same message: "use lists are allocated before the object"? > An llvm::Value (which GlobalVariable is a subtype of) should exist only in the heap. Trying to sort a container of such objects doesn`t require me to

On 12 October 2016 at 14:26, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > Correct me if I misunderstood: you would be ok changing the > reference output to exactly match the output of "-O0 -ffp-contract=off". No, that's not at all what I said. Matching identical outputs to FP tests makes no sense because there's *always* an error bar. The output of O0, O1, O2,

On 10/11/2016 at 4:15 PM, Matthias Braun wrote: > I don't find it surprising that some applications do not work properly with -ffast-math and I think we > have to accept that fact. I think it is valid to skip those tests in the test-suite when a fast math > flag combination is used (after making sure there is no easy way to make the test more robust). > I would add a

Dear all, As part of working on making test-suite less demanding of exact FP results so my FP-contraction patch can go back into trunk and stay there, today I analyzed "MultiSource/Benchmarks/VersaBench/beamformer". I found that the raw output from that program is 2789780 bytes [i.e. ~2.7 _megabytes_] of floating-point text, which IMO is too much to put into a patch -- or at least

----- Original Message ----- > From: "Sebastian Pop via cfe-dev" <cfe-dev at lists.llvm.org> > To: "Renato Golin" <renato.golin at linaro.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Sebastian Paul Pop" <s.pop at samsung.com>, "Abe Skolnik" > <a.skolnik at samsung.com>, "cfe-dev"

On Sep 10, 2016, at 3:33 AM, Steve Canon <scanon at apple.com> wrote: >>> >>> Pretty much. In particular, imagine a user trying to debug an unexpected floating point result caused by conversion of a*b + c into fma(a, b, c). >> >> I think that’s unavoidable, because of the way the optimization levels work. Even fma contraction is on by default (something I’d

On 12 October 2016 at 15:05, Hal Finkel <hfinkel at anl.gov> wrote: > This is something we need to understand. No, there's not always an error bar. With FMA formation and without non-IEEE-compliant optimizations (i.e. fast-math), the optimized answer should be identical to the non-optimized answer. What about architectures that this is never respected, like Darwin? In the general

On 14 October 2016 at 15:50, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > These 3 tests are passing with the following configurations: > -O3 -ffp-contract=off > -O3 -ffp-contract=on > -O0 -ffp-contract=off > -O0 -ffp-contract=on > > They are not passing at: > -Ofast -ffp-contract=on > -Ofast -ffp-contract=off Let's separate completely FP-contract and

On Fri, Oct 14, 2016 at 10:50 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Sebastian Pop" <sebpop.llvm at gmail.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Sebastian Paul Pop" <s.pop at samsung.com>,

> On Sep 9, 2016, at 3:27 PM, Steve Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Sent from my iPhone > > On Sep 9, 2016, at 6:21 PM, Abe Skolnik <a.skolnik at samsung.com <mailto:a.skolnik at samsung.com>> wrote: > >> On 09/09/2016 04:31 PM, Stephen Canon wrote: >> >>> Gating this on -Owhatever is dangerous, .