search for: emitfunc

...m::FunctionType::get(PGOBuilder.getVoidTy(), Args, false); @@ -209,9 +210,10 @@ llvm::Constant *MangledName = CGM.GetAddrOfConstantCString(CGM.getMangledName(GD), "__llvm_pgo_name"); MangledName = llvm::ConstantExpr::getBitCast(MangledName, Int8PtrTy); - PGOBuilder.CreateCall3(EmitFunc, MangledName, + PGOBuilder.CreateCall4(EmitFunc, MangledName, PGOBuilder.getInt32(NumRegionCounters), - PGOBuilder.CreateBitCast(RegionCounters, Int64PtrTy)); + PGOBuilder.CreateBitCast(RegionCounters, Int64PtrTy), +...

...e of the current code (Thumb/Arm) and the latter restoring it, by emiting the $d and $a/t respectively. Does it seem like a good initial approach? Continuing... It seems MCELFStreamer already has a EmitThumbFunc, which looks to me as the wrong place to be. I'd imagine MCELFStreamer would have EmitFunc and MCARMELCStreamer (or whatever) would identify its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being pedantic, even that is still too high level because of the ARM/Thumb veneers, but we don't want to worry about that if LLVM doesn't even try to mix ARM and Thumb (and assumin...

...Continuing... It seems MCELFStreamer already has a EmitThumbFunc, > which looks to me as the wrong place to be. That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. > I'd imagine MCELFStreamer > would have EmitFunc and MCARMELCStreamer (or whatever) would identify > its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being > pedantic, even that is still too high level because of the ARM/Thumb > veneers, but we don't want to worry about that if LLVM doesn't even > try to mix ARM an...

On Oct 5, 2012, at 12:15 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Greg, > >> Is this a bug? If so, how can I fix it? > > It's somewhere between a bug and a quality-of-implementation issue. > ARM often uses literal pools in the middle of code when it needs to > materialize a large constant (or variable address more likely for >

...CELFStreamer already has a EmitThumbFunc, >> which looks to me as the wrong place to be. > > That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. > >> I'd imagine MCELFStreamer >> would have EmitFunc and MCARMELCStreamer (or whatever) would identify >> its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being >> pedantic, even that is still too high level because of the ARM/Thumb >> veneers, but we don't want to worry about that if LLVM doesn't even >> t...

I've built chromium with " -fprofile-instr-generate -fsanitize=address" -- the performance looks good! The file format from r198638 is indeed rudimentary. Do you already know how the real output format will look like? Just to summarize what I think is important: - minimal size on disk, minimal amount of files - minimal i/o while writing to disk, no lockf or some such -

...EmitThumbFunc, >>> which looks to me as the wrong place to be. >> >> That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. >> >>> I'd imagine MCELFStreamer >>> would have EmitFunc and MCARMELCStreamer (or whatever) would identify >>> its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being >>> pedantic, even that is still too high level because of the ARM/Thumb >>> veneers, but we don't want to worry about that if LLVM doesn't eve...