similar to: [LLVMdev] C embedded extensions and LLVM

On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > I've been playing around with clang/LLVM looking at adding partial > support for the draft technical report for embedded C extensions > (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ > n1169.pdf), specifically named address spaces. > > Named address spaces need to be tracked in LLVM in essentially all

On Nov 11, 2007, at 9:52 AM, Chris Lattner wrote: > > On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > >> I've been playing around with clang/LLVM looking at adding partial >> support for the draft technical report for embedded C extensions >> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1169.pdf), specifically named address

On Nov 11, 2007, at 9:52 AM, Chris Lattner wrote: > > On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > >> I've been playing around with clang/LLVM looking at adding partial >> support for the draft technical report for embedded C extensions >> (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ >> n1169.pdf), specifically named address

On Aug 21, 2007, at 11:10 PM, Duncan Sands wrote: > Hi Christopher, > >> In C/C++ a restrict pointer is also assumed not to alias any other >> parameters, global values or local value. However the compiler must >> not assume that pointers "based on" a restrict pointer do not alias. > > does "based on" mean something like: copies of the pointer

On Mon, 26 Mar 2007, Christopher Lamb wrote: >> For representing scoping information, a relatively non-invasive >> approach is to introduce a special "copy" operation, which in LLVM >> might look like >> %a = copy %b >> This operation has to be somewhat special in that can't be folded away >> in most cases, but it can otherwise be pretty

Hi Christopher, > >> In C/C++ a restrict pointer is also assumed not to alias any other > >> parameters, global values or local value. However the compiler must > >> not assume that pointers "based on" a restrict pointer do not alias. > > > > does "based on" mean something like: copies of the pointer made in the > > function body?

On Tue, Mar 1, 2011 at 4:06 PM, David Neto wrote: > On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne wrote: >> >> The more I think about it, the more I become uncomfortable with the >> concept of language-specific address spaces in LLVM.  These are the >> main issues I see with language-specific address spaces: > > ... > >> Instead of language-specific

Hi All , Was going through the C99 standard @ http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf which states that the Function declarators as direct-declarator ( parameter-type-list ) parameter-list: parameter-declaration parameter-list , parameter-declaration parameter-declaration: declaration-specifiers declarator

On 10/10/2016 14:59, Stephan Bosch wrote: > > > Op 10-10-2016 om 14:39 schreef Michael Felt: >> On 10-Oct-16 06:45, Aki Tuomi wrote: >>> Does your build end at some particular point? >> See **** DETAILS **** for in depth (I hope enough!) study/report. >>> >>> Aki >> >> I would guess this is not "c99" way... > > It seems to

On Mar 26, 2007, at 10:10 AM, Dan Gohman wrote: > On Mon, Mar 26, 2007 at 02:14:56AM -0500, Christopher Lamb wrote: >> >> >> On Mar 25, 2007, at 5:22 PM, Chris Lattner wrote: >> >>> On Sun, 25 Mar 2007, Christopher Lamb wrote: >>>> What about an approach not unlike how debugging information is >>>> handled? That >>>> is have

On Aug 21, 2007, at 6:12 AM, Duncan Sands wrote: > Hi Christopher, > >> The benefits of a const * __restrict come from two different places. >> The const part is essentially enforced by the front-end and the >> restrict part is used to inform the alias analysis (it becomes a >> noalias parameter attribute). The noalias parameter attribute may be >> of use to

Hi Kevin, On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote: > So only "non-freed" malloc pointers are No-Alias which makes it > flow-sensitive. There is no reason why malloc couldn't return previously > freed location. Yes. Talking to Nick Lewycky on IRC, I figured out a shorter way of saying what I wanted to say.  We know that programs like this

Chris, Extending LLVM IR to support PointerTypes that take an address space is what I was hoping to avoid. However, if we want to do things right, that is probably the way to go. Now that we got here, let me write some of my thoughts on this and solicit your input: --- 1) Syntax extension: In our existing compiler for 8-bit microcontrollers, we have introduced rom and ram qualifiers (with ram

On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote: > On Wed, 21 Nov 2007, Christopher Lamb wrote: >>> Unlike alignment and volatility, I think that the address space >>> qualifier >>> should be represented explicitly in the type system. The reason >>> for this > >> I've come across a hitch. Store instructions do not reference the

On Nov 11, 2007, at 9:52 AM, Chris Lattner wrote: > Unlike alignment and volatility, I think that the address space > qualifier should be represented explicitly in the type system. The > reason for this is primarily that pointers to different address > spaces are really very different sorts of beasties: for example > they can be codegen'd to have different sizes. Any

Hi Jianzhou, > I misunderstood C99 ISO, such behaviors are defined not when types > have the same sizes, but when they are same (compatible) types with > signed or qualified extension (this is much stronger than being of > same sizes), or reading char by char: > > 7 An object shall have its stored value accessed only by an lvalue > expression that has one of > the

Ben Allison wrote: > As mentioned before, this removes some of the 'inline' from the bitreader > and bitwriter functions that were used in another translation unit. I'm > surprised that this code works on other platform. It must be a bug in > GCC, or maybe deliberately non-standard behavior. See 6.7.4 of the C99 > spec for details. I've read section 6.7.4 from

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

On Wed, 2008-05-14 at 13:26 -0400, David Vandevoorde wrote: > On May 14, 2008, at 10:46 AM, Jonathan S. Shapiro wrote: > > On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: > >> Jonathan S. Shapiro wrote:- > >>> Is there a requirement somewhere in the C *Language* Specification > >>> that > >>> ties all of this together in the required

On 9/14/20 9:30 AM, James Y Knight via llvm-dev wrote: > On Mon, Sep 14, 2020 at 3:19 AM László Radnai via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> A problem arises, and I am not sure if it is really a problem or just >> weird C-compliant behavior. >> >> int a; // or, equally, int a=0; >> >> int main(){ >> int b; >> if