similar to: bitcode versioning

Is there going to be a formal interface/API for this version-block information? I have had to "extend" the IR and bitcode representations several times to address absences/limitations in the handling of various vector types, in particular FP16 vector types; and it would be really useful if I had a "standard" way of doing this, and identifying that my dialect was different.

Hi Mehdi and my apologies for the delay in responding - the day job got in the way :-) Our target is still out-of-tree so my reasons for extending the IR would be eliminated if we were a proper part of LLVM, which I would like to do when the time is right for us. My extensions are quite simple really, and I expect that they will be wanted in the TRUNK sometime anyway. At the moment I only have

Reid Spencer <rspencer <at> reidspencer.com> writes: > Hi Joshua, Hi, thanks for the reply. > On Mon, 2007-09-03 at 21:34 +0000, Joshua Haberman wrote: > > I also have a few questions about the format: > > > > - it appears that the only magic number in the file is > > application-specific. This seems unfortunate, because it means that > >

Are you saying the textual form of IR can change, but bitcode doesn't? I don't know what you mean by assembly syntax. Is there a changlog entry when the textual IR changes? On Sat, Mar 14, 2015 at 5:22 AM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > Assembly syntax can and will break between versions. But bitcode should > generally be upgradeable, or a bug should

Another round of improved patches, and a patch for documentation changes to LangRef. * Make comments more up to date * Use 'arcp' instead of 'ar' * Use logical || Still based off of r168110 On Nov 15, 2012, at 3:31 PM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: >

Seems like a nice cleanup to me! > On 2016-Nov-07, at 13:01, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I want to clarify / emphasize two things based on an off-list > conversation: > > - The bitcode and IR parser both auto upgrade old style TBAA to the > newer TBAA struct tags. Shouldn't we drop the textual IR

Hi, As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing

Trying to apply patches.. What's your base revision? Joe On Nov 15, 2012, at 5:44 PM, Michael Ilseman <milseman at apple.com> wrote: > New patches with review feedback incorporated: > * Changed single letter flags to short abbreviations ('S' ==> 'nsz') > * Indentation fixes > * Comments don't state function names > >

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not

On Nov 15, 2012, at 10:38 AM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Michael, > > The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A' seem cryptic to me. Does it make sense to expand them a bit 'nnan', 'inf', etc.? They definitely

2017-06-07 10:19 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > On Wed, Jun 7, 2017 at 10:01 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-06-07 9:44 GMT-07:00 David Blaikie <dblaikie at gmail.com>: >> >>> >>> >>> On Tue, Jun 6, 2017 at 2:21 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >>>

Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. + bool any() { + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | + AllowReciprocal; + } Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: SubclassOptionalData = (SubclassOptionalData & ~BitToSet) | (B * BitToSet); This is

2017-06-07 9:44 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > On Tue, Jun 6, 2017 at 2:21 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> 2017-06-06 13:38 GMT-07:00 David Blaikie <dblaikie at gmail.com>: >> >>> >>> >>> On Tue, Jun 6, 2017 at 1:26 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >>>

Attached are some patches for adding in an IR-level mechanism for representing fast-math flags, as discussed in my prior RFC. Patches include infrastructure, API support, textual and bitcode reader/writer support, example optimization, and test cases. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type:

On Nov 15, 2012, at 10:51 AM, Michael Ilseman <milseman at apple.com> wrote: > > On Nov 15, 2012, at 10:38 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> Hi Michael, >> >> The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A'

> Could you please describe what is the benefit of that? Currently there are two ways to provide DISPFlagDefinition, via bool and SPFlag, I would like to make it only via SPFlags, it will be NFC and it will make the changes in parser simpler for moving five flags from from DIFlags to DISPFlags. Currently parser checks the presence of SPFlags to see if the definition is present in bool or spflag

On Nov 14, 2012, at 12:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > >> I think I missed what problem we're trying to solve here. >> >> I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal

Hi Michael, The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A' seem cryptic to me. Does it make sense to expand them a bit 'nnan', 'inf', etc.? They definitely need to be documented. Evan On Nov 15, 2012, at 10:17 AM, Michael Ilseman <milseman at

On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. > > + bool any() { > + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | > + AllowReciprocal; > + } > Will do. > Gripe: This pattern is probably super fast and has

Michael, Overall the code looks good. 80-cols: 2046 FMF.UnsafeAlgebra = 0 != (Record[OpNum] & (1 << bitc::FMF_UNSAFE_ALGEBRA)); 2047 FMF.NoNaNs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_NANS)); 2048 FMF.NoInfs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_INFS)); 2049 FMF.NoSignedZeros = 0 !=