search for: attribute_lists

On Nov 26, 2012, at 3:20 PM, Bill Wendling wrote: >> 4. Do we really want the attribute references limited to a number? Code will be more readable >> if you can use actual names that indicate the intent. For example: >> >> attrgroup #compile_options = { … } >> void @foo attrgroup(#compile_options) >> > The problem with this is it

On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > IR Changes > ---------- > > The attributes will be specified within the IR. This allows us to generate code > that the user wants. This also has the advantage that it will no longer be > necessary to specify all of the command line options when compiling the bit code > (via 'llc' or 'clang'). E.g.,

On Nov 20, 2012, at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to specify

On Tue, Nov 20, 2012 at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to

Hi! This is a proposal to expand the Attributes class to support many different options that will be accessible by all parts of the compiler. Please read and give any feedback you may have. Thanks! -bw Passing Options to Different Parts of the Compiler Problem ======= There is a growing need to pass information from the front-end to different parts of the compiler, especially

Hi all, - There is a worth thing to note about these changes, which is the handling of $ATTRIBUTE_LIST attribute, that is rare attribute. When there are a lot of attributes and there is no more space in the MFT record, all those attributes that can be made non-resident are moved out the MFT, so this is where the $ATTRIBUTE_LIST comes in. - Most people must have seen the ugly "EDD

Hi! The rewrite of the attributes class is well underway. The next step is to add support for the expanded rôle of attributes in the language and IR. This is the final proposal for the language changes. There isn't a lot of new information except for the syntax changes for the new feature. Executive Summary: The new syntax is: #0 = attributes { noinline align=4

On Jan 29, 2013, at 2:42 PM, Bill Wendling <isanbard at gmail.com> wrote: > Executive Summary: > > The new syntax is: > > #0 = attributes { noinline align=4 "cpu"="cortex-a8" } > #1 = attributes { attr = (val1 val2 val3) } > #bork = attributes { sspreq noredzone } > > define void @foo() #0 #bork { ret void } The general syntax LGTM. It

On Feb 3, 2013, at 10:45 AM, Chris Lattner <clattner at apple.com> wrote: > On Jan 29, 2013, at 2:42 PM, Bill Wendling <isanbard at gmail.com> wrote: >> Executive Summary: >> >> The new syntax is: >> >> #0 = attributes { noinline align=4 "cpu"="cortex-a8" } >> #1 = attributes { attr = (val1 val2 val3) } >>

Couple of quick questions: First, what are the valid types for <value>? Are they always strings which the target must interpret, or will numeric literals and booleans also be supported? Also, in the proposal, attributes are sometimes quoted and sometimes they are not. I know this is nit-picking, but what is the preferred syntax? Second, would it make sense to fold the calling convention

Dear all, I have used Markdown via Drupal a few months now, with a customer site and my currently my own blog and based on that practical experience I wanted to add some extra functionality to PHP Markdown Extra, so out of this grow my (extended) weekend project https://github.com/egil/php-markdown-extra-extended The big missing item right now that I would like to implement is the ability to add

Patch ready for merging. v4: - check return code of tsk_fs_attr_walk - pass TSK_FS_FILE_WALK_FLAG_NOSPARSE as additional flag to tsk_fs_attr_walk After discussing with TSK authors the behaviour is clear. [1] In case of COMPRESSED blocks, the callback will be called for all the attributes no matter whether they are on disk or not (sparse). In such cases, the block address will be 0. [2] So

Hi folks, I expect that the response to this post will be "we don't need such a thing", but humour me for a moment by pretending that in fact we do. HTML5 added a number of new tags to the mix, but arguably the most significant is the `time` element. It associates a machine-readable timestamp with a human-readable string (e.g. `<time