search for: cgcontext

...> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started, > attached is patch which implements a pretty minimal skeleton of a CGContext > implementation. The goal is to allow the newly added subtarget attributes > on functions to be made available to codegen so that codegen can actually > switch subtargets within a Module. > > > > Comments and questions are invited herewith. > > > > There has been s...

....com> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen can actually switch subtargets within a Module. > > > > Comments and questions are invited herewith. > > > > There has been some disagreemen...

...amic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext > > So CGContext could still live inside libTarget. CGContext would be > initialized for a Function based on the attributes and the information > already in its container, TargetMachine. > > It sounds like you would be making CGContext part of libCore instead, like > this: >...

On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello llvm-dev, > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen can actually switch subtargets within a Module. > > Comments and questions are invited herewith. > > There has been some disagreement as to what to na...

Hello llvm-dev, Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen can actually switch subtargets within a Module. Comments and questions are invited herewith. There has been some disagreement as to what to name this class. I hav...

...o be done here before it can go in? I feel like most of our discussion centered around future work, and I'd like to unblock the immediate work to support subtarget-specific code generation. > > Do we have a solution that can work with TTI? I don’t think there was any objection to putting CGContext in TargetMachine, except that we have too many layers of abstraction, which you said will be cleaned up eventually: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext >...

...at needs to be done here before it can go in? I feel like most of our discussion centered around future work, and I'd like to unblock the immediate work to support subtarget-specific code generation. Do we have a solution that can work with TTI? I don’t think there was any objection to putting CGContext in TargetMachine, except that we have too many layers of abstraction, which you said will be cleaned up eventually: IR Transform (links with) -> TargetTransformInfo (dynamic call) -> X86TTI (links with) -> TargetMachine (provides) -> CGContext -Andy > > > On Thu, D...

...ic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext > > So CGContext could still live inside libTarget. CGContext would be > initialized for a Function based on the attributes and the information already in its container, TargetMachine. > > It sounds like you would be making CGContext part of libCore instead, like this: > > I...

...e-soft-float'). -------------------------------------------------------------------------------- Before we get further, here are a few definitions used in this document: Back-end Objects :: Objects that affect code generation --- e.g., TargetInstrInfo, TargetFrameLowering, DataLayout, etc. CGContext :: A central repository for back-end objects. The back-end objects may change, so they should not be "cached" by individual passes. This is analogous to the current TargetMachine object. The term "CGContext" is used because it separates the current implementation from the &quot...

On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello llvm-dev, > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen can actually switch subtargets within a Module. > > Comments and questions are invited herewith. > > There has been some disagreement as to what to na...

...; > Cheers! > > -bw Thanks, Bill. I do have some comments, but first I want to apologize for not sending them earlier. Bill had asked for feedback before sending this out to a wider audience but I didn’t get to it until now. Sorry Bill! [ background description removed ] > > CGContext :: > > A central repository for back-end objects. The back-end objects may change, so > they should not be "cached" by individual passes. This is analogous to the > current TargetMachine object. The term "CGContext" is used because it > separates the current impl...

On Oct 13, 2013, at 2:35 PM, Bob Wilson <bob.wilson at apple.com> wrote: > On Oct 12, 2013, at 1:55 AM, Bill Wendling <isanbard at gmail.com> wrote: > >> CGContext :: >> >> A central repository for back-end objects. The back-end objects may change, so >> they should not be "cached" by individual passes. This is analogous to the >> current TargetMachine object. The term "CGContext" is used because it >> separa...

...if the driver doesn’t initialize them. I > don’t want any way to accidentally run the vectorizer or LSR without > initializing my subtarget info. Also, I want to prevent early passes from > getting at subtarget info. > <snip> > > Passes that depend on TargetMachine can use CGContext for hard target and > subtarget info queries. Since they must depend on TargetMachine anyway, > they can do something like TM.getCGContext(Function). > This sounds like you want IR-level passes which have direct, hard dependencies on the target and codegen. That would be a radical departu...

On Oct 13, 2013, at 8:23 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Oct 13, 2013, at 2:35 PM, Bob Wilson <bob.wilson at apple.com> wrote: > >> On Oct 12, 2013, at 1:55 AM, Bill Wendling <isanbard at gmail.com> wrote: >> >>> CGContext :: >>> >>> A central repository for back-end objects. The back-end objects may change, so >>> they should not be "cached" by individual passes. This is analogous to the >>> current TargetMachine object. The term "CGContext" is used because it...

...that fail if the driver doesn’t initialize them. I don’t want any way to accidentally run the vectorizer or LSR without initializing my subtarget info. Also, I want to prevent early passes from getting at subtarget info. > > <snip> > > Passes that depend on TargetMachine can use CGContext for hard target and subtarget info queries. Since they must depend on TargetMachine anyway, they can do something like TM.getCGContext(Function). > > This sounds like you want IR-level passes which have direct, hard dependencies on the target and codegen. That would be a radical departure fr...

On Thu, Dec 5, 2013 at 7:36 PM, Andrew Trick <atrick at apple.com> wrote: > It might nice if scalaropts did not need to link against libTarget—we > could easily avoid introducing more dependence on libTarget if that’s a > goal. > We already have that state today in the overwhelming majority of the cases. The pass manager built by the PassManagerBuilder doesn't need a target

...ndler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) () #15 0x9805ce50 in DispatchEventToHandlers () #16 0x9805d0c4 in SendEventToEventTargetInternal () #17 0x98061544 in SendEventToEventTargetWithOptions () #18 0x98068ba8 in SendControlDefDraw(HIView*, short, OpaqueGrafPtr*, OpaqueRgnHandle*, CGContext*) () #19 0x98062cf8 in HIView::DrawComposited(OpaqueRgnHandle*, unsigned long, HIView*, CGContext*) () ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=7146&group_id=35

...een created I get a segfault on exit on OS X. Think ClientDC should be managed using a block in the same way as PaintDC. Backtrace is: Program received signal EXC_BAD_ACCESS, Could not access memory. 0x98bc1cbc in CGGStateRelease () (gdb) whe #0 0x98bc1cbc in CGGStateRelease () #1 0x98bc5f78 in CGContextRestoreGState () #2 0x036d8a74 in wxMacCoreGraphicsContext::SetNativeContext(CGContext*) () #3 0x036d7e70 in wxMacCoreGraphicsContext::~wxMacCoreGraphicsContext() () #4 0x034cea44 in wxDC::~wxDC() () #5 0x034cdc6c in wxWindowDC::~wxWindowDC() () #6 0x034ce24c in wxClientDC::~wxClientDC() () #7...

...mach_msg_trap 58 mach_msg_trap 1 _CGSGetSurfaceBinding 25 _CGSFlushSurfaceInline 25 mach_msg 25 mach_msg_trap 25 mach_msg_trap 2 CGContextFlush 2 ripc_Operation 2 CGSDeviceSynchronize 2 _CGSFlushRegionInline 1 _CGSFlushRegionInline 1 mach_msg 1 mach_msg_trap 1 m...

...AppKit) [0x953e38f1] 2 MetalSheetProgress + 8460 (in CoreGraphics) [0x98b03028] 2 resizeTopShadow + 406 (in CoreGraphics) [0x98b04f84] 2 CGContextFillRect + 32 (in CoreGraphics) [0x98a44efc] 2 CGContextFillRects + 159 (in CoreGraphics) [0x98a02370] 2 ripc_DrawRects + 622 (in libRIP.A.dylib) [0x92c6645c]...