On Mon, Sep 16, 2013 at 7:14 PM, Ilya Verbin wrote:
> Hi Richard,
>
> On 23 Aug 14:24, Richard Biener wrote:
>> Ilya Verbin wrote:
>> >I'm trying to implement the approach with modified lto-wrapper.
>> >Suppose we have a bytecode of the routine foo, streamed during ompexp
>> >pass into some secti
On 17 Sep 10:12, Richard Biener wrote:
> It looks more like a hack ;) It certainly doesn't look scalable to multiple
> target ISAs. You also unconditionally invoke the target compiler (well, you
> invoke the same compiler ...)
Yes, I currently call the "target" compiler unconditionally, but it c
On Tue, Sep 17, 2013 at 03:30:10PM +0400, Ilya Verbin wrote:
> On 17 Sep 10:12, Richard Biener wrote:
> > It looks more like a hack ;) It certainly doesn't look scalable to multiple
> > target ISAs. You also unconditionally invoke the target compiler (well, you
> > invoke the same compiler ...)
>
On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin wrote:
> On 17 Sep 10:12, Richard Biener wrote:
>> It looks more like a hack ;) It certainly doesn't look scalable to multiple
>> target ISAs. You also unconditionally invoke the target compiler (well, you
>> invoke the same compiler ...)
>
> Yes, I c
> > 1.2. Linking
> >
> > When all source files are compiled, a linker is invoked. The linker is
> > passed
> > a special option to invoke openmp-plugin. The plugin is responsible for
> > producing target-side executables - for each target it calls the
> > corresponding
> > target compiler and
On Tue, Sep 17, 2013 at 01:56:39PM +0200, Richard Biener wrote:
> On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin wrote:
> > On 17 Sep 10:12, Richard Biener wrote:
> >> It looks more like a hack ;) It certainly doesn't look scalable to
> >> multiple
> >> target ISAs. You also unconditionally invok
On Tue, Sep 17, 2013 at 04:04:54PM +0400, Michael V. Zolotukhin wrote:
> > ... and the first GOMP_target,
> > GOMP_target_data or GOMP_target_update from a particular shared library or
> > binary (all of them will have __OPENMP_TARGET__ weak hidden symbol as one of
> > the arguments) offloads the e
Hi,
For a special mechanism we are generating jump_insn with a 'set' side
effect in our backend. RTL looks e.g. like this:
(jump_insn 25 24 26 (nil) (parallel [
(set (pc)
(if_then_else (ne (unspec_volatile [
(const_string (" %0,[%1] =%2"
On Mon, Sep 16, 2013 at 1:43 AM, zhaobin xv wrote:
>
> As I know in C :
> a. Global and static variables locate at data segment
> b. When a function is called, memory is allocated on the stack to hold
> parameter values, local variables, and the address of the calling
> function
> c. the struct is
Richard, this sounds very good. Let me try this. So far, what I meant
by 'reloading myself' was that when generating the RTL above, I
actually emit move instructions to/from memory if the arguments are
memory, and generate RTL above only with hard registers. I did not
mention that RTL expansion is
Hendrik Greving writes:
> For a special mechanism we are generating jump_insn with a 'set' side
> effect in our backend. RTL looks e.g. like this:
>
> (jump_insn 25 24 26 (nil) (parallel [
> (set (pc)
> (if_then_else (ne (unspec_volatile [
>
On Wed, Sep 4, 2013 at 6:48 AM, Kenny Simpson wrote:
> http://gcc.gnu.org/wiki/FunctionMultiVersioning says "This support has been
> checked in to trunk and should be available when GCC 4.8 is released."
>
>
> Since 4.8 has been released, and lists multiversioning support in the release
> notes
One follow-up question here. Is it of any disadvantage to always
generate a clobber (scratch) during expansion? Meaning that in the
case we don't need one (we won't split, which I am checking with
memory_operand(myoutput_operand), that register won't get allocated
and adds to register pressure, doe
13 matches
Mail list logo
