similar to: [LLVMdev] llvm demo

On Apr 14, 2010, at 9:05 AM, Eugene Toder wrote: > Hi All, > > One of possibly minor but a very cool things about LLVM has always > been the online demo on llvm.org. > Now that we have clang, I think it will be great if the demo allowed > to use it as C/C++ front-end. > This will be especially useful for testing what kind of C++ clang > accepts/can already handle. I

Hi, Here's a patch for online demo on llvm.org that - Extends language selection to allow - A choice between clang and llvm-gcc - Entering llvm assembly directly (and uploading .ll and .bc files) - Makes handling of uploaded files binary safe (mostly for bc files) - Fixes code to produce valid xhtml 1.1 - Contains a lot of minor cleanup changes that make the patch big, sorry! Should

> The clang driver generally uses an installed gcc to do the assemble > and link steps at the moment. gcc? I thought it uses binutils. Eugene

I see. I assumed it runs binutils directly. Eugene On Wed, Jul 7, 2010 at 10:02 PM, Eric Christopher <echristo at apple.com> wrote: > > On Jul 7, 2010, at 1:55 PM, Eugene Toder wrote: > >>> The clang driver generally uses an installed gcc to do the assemble >>> and link steps at the moment. >> >> gcc? I thought it uses binutils. > > > The gcc

Oh yes you're right, I missed that :) But the point still hold. Amaury Pouly 2010/8/8 Eugene Toder <eltoder at gmail.com> > > Not only this code does not compile with NDEBUG set > > I may be missing something, but why does it not compile with -DNDEBUG? > assert() macro expands to noop when NDEBUG is set. > > Eugene > > On Sun, Aug 8, 2010 at 2:19 PM, Amaury

On Aug 19, 2013, at 18:47 , Eugene Toder <eltoder at gmail.com> wrote: > Have you tried running SLP vectorizer pass (-vectorize-slp)? Yes. That was the first thing i tried, and it didn't do anything. I was looking the vectorizer, but then I saw some things that made me wonder if it was even supposed to do this

I don't think licm looks at loads/stores to allocas -- these are usually handled by mem2reg which happens much earlier (if you run your example with -mem2reg you'll see it already deleted the store). In fact, licm sinks the stores by converting them to stores to allocas first and running mem2reg on that. If you change your example to void testLICM(int* restrict p) { int i,N=100;

Yes, I'm not arguing that there is a dependence, just that it's not a clobber dependence. The case of a load is already considered earlier in that function and with isLoad == false it returns MemDepResult::getDef(). My question is: why should a read-only call (which yields AliasAnalysis::Ref and is handled in this code fragment) be any different from e.g. a load. Isn't a read-only

Right, later in the same file we have: // Reserve entries in the vector for each of the SUnits we are creating. This // ensure that reallocation of the vector won't happen, so SUnit*'s won't get // invalidated. // FIXME: Multiply by 2 because we may clone nodes during scheduling. // This is a temporary workaround. SUnits.reserve(NumNodes * 2); So for some reason *2 is

Hi, I am trying to understand how assume shaped arrays are received and processed in LLVM IR. I am using "flang" for my front end. There seems to be an array descriptor received as implicit argument for every assume shaped array. For my test routine: ---snip-- SUBROUTINE test(a,b,Li,Lj,Istr,Iend,Jstr,Jend) INTEGER, INTENT(IN) :: Li,Lj INTEGER, INTENT(IN) :: Istr, Iend,

Hello, I believe these descriptors are specific to flang, not to LLVM. You should probably ask your question on flang-dev list. Thank you, --Eugene From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Venkataramanan Kumar via llvm-dev Sent: Wednesday, April 25, 2018 8:44 AM To: llvm-dev at lists.llvm.org Subject: [llvm-dev] Help on understanding assume shape array

On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote: > Is this a recommended approach/good style/good idea to use > dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other > is and cast functions). We generally don't want auto-dereference. There is some special magic for unwrapping Uses etc though. Is this what you're in contact with Gabor? -Chris >

I am studying the Transform/Scalar/LICM.cpp pass, and wrote a simple test program to validate. void testLICM(void){ int i,N=100; int data; for(i=0;i<N;i++){ data = 1; printf("i: %d\n",i); } printf("data: %d\n", data); } I expect the "data=1" will be moved out of loop (either hoist or sink). However, to my surprise, that statement

On Jun 27, 2010, at 2:26 PM, Eugene Toder wrote: > Hi Dan, > > Are you referring to my reasoning for why _length and _data[i] do not > alias? No, I was referring to the discussion of C99 6.7.2.1, 6.5.6, 6.2.6, and so on. > I don't think this needs TBAA or any "strict" aliasing rules. > All that sufficient is 1) assumption about struct layout: >

Sorry, I misunderstood the question. The difference between a load and a read-only call is that load can be used as the value of the memory location. E.g. DeadStoreElimination pass removes a store that stores a just loaded value back into the same location. To do this it checks if the stored value is the value of load. Read-only call cannot be used like this. This being said, I don't know if

Yes, the global structure is constant. This is indeed a side-table. Overriding section of global to be in text is simple -- LLVM already supports section attribute on globals and functions. However we also need a specific ordering in text. With some extra work this ordering can be achieved with gnu linker (I posted example implementation earlier) without any changes to LLVM, so the main points for

On Jul 7, 2010, at 1:55 PM, Eugene Toder wrote: >> The clang driver generally uses an installed gcc to do the assemble >> and link steps at the moment. > > gcc? I thought it uses binutils. The gcc driver that runs whatever is appropriate for the system. -eric

Hello Eugene, The underlying problem here is that your reasoning below follows C rules, while BasicAA and other LLVM passes must follow LLVM IR rules, which are different in this area. In LLVM IR, memory has no types. Translating from C to LLVM IR does not preserve this information. In addition to being the reason BasicAA can't reason about array bounds and struct members as you describe,

Let me point out that projects using standard toolchain (e.g. binutils) can already reorder code and data pretty much arbitrary using sections and linker scripts. I think it's still attractive to have reordering in LLVM to be independent from external toolchain. This will allow reordering in JIT and other interesting things. I agree with John that special global with ordered list looks like

Subsections is a very good idea. You can even do without post-processing by using carefully crafted section names, e.g. __attribute__((section(".text,\"ax\", at progbits\n\t.subsection 1 #"))) void foo() { } (Note that you need ".subsection n" commands on ELF targets and ".section name, n" commands on COFF targets; seems that the latter was supported on