similar to: [LLVMdev] MDBuilder - helper for making metadata

On Sun, Apr 15, 2012 at 3:35 PM, Duncan Sands <baldrick at free.fr> wrote: > Here's a first attempt at a MDBuilder class that makes it easier to create > metadata. It has utilities for creating range and tbaa metadata (which by > a strange coincidence are the kinds used by dragonegg). > This seems like a fine interface. I'd love it for folks more familiar w/ the

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the

Hi Duncan, I like the changes to IRBuilder and how the operator can't change it. Looks a lot safer (mistake-wise) and more convenient. This function won't to remove a previously set tag, which could be used by optimisations or inlining. + Instruction *AddFPMathTag(Instruction *I, MDNode *FPMathTag) const { + if (!FPMathTag) + FPMathTag = DefaultFPMathTag; + if (FPMathTag) +

I'm looking at fixing some layering violations in LLVM & came across a few in the CodeView handling, specifically: lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers I guess MC could be made dependent on DebugInfoCodeView? But probably these things should be sunk into BinaryFormat as is the case for DWARF features used by MC? include/llvm/Object/COFF.h includes

Hi Owen, > I have some issues with representing this as a single "fast" mode flag, it isn't a single flag, that's the whole point of using metadata. OK, right now there is only one option (the "accuracy"), true, but the intent is that others will be added, and the meaning of accuracy tightened, later. MDBuilder has a createFastFPMath method which is intended to

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today,

Someone internally's been dabbling with turning on some of Google's build system's stricter header checking modes - and they caught these (you can check the internal code review 184305506 for the original where I'm pulling things out from). & yeah, fair question about the modules builds - I don't fully understand what they catch and don't catch. I suspect it's a

Yes, some of the headers and stuff that are just raw structure definitions and enums could probably be sunk into BinaryFormat.. How'd you find this? Curious why it hasn't been breaking in modules builds for a long time. On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > I'm looking at fixing some layering violations in LLVM & came across a

Full_Name: Tadashi Kadowaki Version: 2.4.0 OS: Redhat Linux 9 Submission from: (NULL) (58.12.166.67) Doesn't nls function support subset? It seems not to work. And, there are no information in the online help. Has it sunk into oblivion?

On 05/05/2014 10:14, Pekka Jääskeläinen wrote: > On 05/02/2014 07:22 PM, Humphreys, Jonathan wrote: >> Thanks for the link. I understand your concern of caution with metadata. >> I cannot, though, imagine how the dependence relation (independence) >> of two >> memory references can be affected by a third memory reference. If two >> references are independent

On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: > On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > >> I'm looking at fixing some layering violations in LLVM & came across a >> few in the CodeView handling, specifically: >> >> lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers

Intuitively I'd think MC and DebugInfo should be independent. MC is a producer, DebugInfo is a consumer. What's common is the definition of the structures they operate on, which doesn't properly belong to either one. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev Sent: Wednesday, March 21, 2018 11:52 AM To: Zachary Turner

Hello. I am not sure this is the right place to ask but here is my question. About a year ago there was a fix of some obscure bug (rdar://problem/8030636 which is located on the internal Apple bugtracker I believe and so not available to the general public :)) Some discussion can be found here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100531/102160.html. Unfortunately, no

In plotmath expressions, R's degree symbol, e.g. shown by plot(1, main = parse(text = "1*degree*C")) has sunk to halfway the text line, instead of touching its top. In older R versions this looked much better. -- Edzer Pebesma Institute for Geoinformatics Heisenbergstrasse 2, 48151 Muenster, Germany Phone: +49 251 8333081

DebugInfoCodeView is nto strictly a consumer, it is also a producer. On Wed, Mar 21, 2018 at 1:29 PM <paul.robinson at sony.com> wrote: > Intuitively I'd think MC and DebugInfo should be independent. MC is a > producer, DebugInfo is a consumer. What's common is the definition of the > structures they operate on, which doesn't properly belong to either one. > >

It seems a little strange conceptually that object depends on BitcodeReader. Is it possible to break that dependency? On Thu, Mar 29, 2018 at 4:11 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Mar 26, 2018 at 4:52 PM David Blaikie <dblaikie at gmail.com> wrote: > >> On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: >>

On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > I'm looking at fixing some layering violations in LLVM & came across a few > in the CodeView handling, specifically: > > lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers > I guess MC could be made dependent on DebugInfoCodeView? But probably > these things should be

(and sys::cas_flag that STATISTIC uses is a uint32 ...) On Thu, Aug 25, 2016 at 9:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > Okay, dumb question: > Are you really getting negative numbers in the second column? > > 526,766 -136 mem2reg # PHI nodes inserted > > http://llvm.org/docs/doxygen/html/PromoteMemoryToRegister_8cpp_source.html >

Help-Rs,   I've got three vectors representing participants:   vec1 <- c(4,5,6,7,8,9,10,11,12,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81) vec2 <- c (1,2,3,4,5,6,7,8,9,10,11,12,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66) vec3 <- c (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,52)   I'd

Will do. I will write something up. Hal, your concern below isn't so much with the proposed semantics but rather with the use - that optimizations must respect the loop for which the metadata applies, correct? Thanks Jon -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, May 05, 2014 4:00 AM To: Tobias Grosser Cc: Pekka Jääskeläinen; Humphreys, Jonathan;